Moving/Using Postgres Binaries on multiple machines
If I want to create a postgres database on multiple machines, is the
practice of tarring or zipping up binaries compiled on one machine and
untarring them on another, and using the binaries (initdb etc) acceptable?.
This removes the need for having a compiler and environment on the target
machine, or is it necessary always to have such an environment on any
machine you intend to use postgres on? Postgres seems to have enough
environment options to allow this to work, overriding the original library
locations and paths etc from the original machine on which postgres was
compiled.
Does anyone see a problem with this approach?
Thanks!
Francis
Francis Reed wrote:
If I want to create a postgres database on multiple machines, is the
practice of tarring or zipping up binaries compiled on one machine and
untarring them on another, and using the binaries (initdb etc) acceptable?.
This removes the need for having a compiler and environment on the target
machine, or is it necessary always to have such an environment on any
machine you intend to use postgres on? Postgres seems to have enough
environment options to allow this to work, overriding the original library
locations and paths etc from the original machine on which postgres was
compiled.Does anyone see a problem with this approach?
Possibly hundreds. You clearly can't move from Sun/SPARC to BSD/x86 to
Linux/PPC. What platform are you interested in and why isn't there a
package manager for it?
--
Richard Huxton
Archonet Ltd
Sure, this is what Linux distributers do. They compile postgresql into
a binary package which is installed on the user's machine.
It works as long as the environments are reasonably compatable, all
have readline, similar libc, etc.
Hope this helps,
On Wed, Nov 24, 2004 at 12:30:28PM -0000, Francis Reed wrote:
If I want to create a postgres database on multiple machines, is the
practice of tarring or zipping up binaries compiled on one machine and
untarring them on another, and using the binaries (initdb etc) acceptable?.
This removes the need for having a compiler and environment on the target
machine, or is it necessary always to have such an environment on any
machine you intend to use postgres on? Postgres seems to have enough
environment options to allow this to work, overriding the original library
locations and paths etc from the original machine on which postgres was
compiled.Does anyone see a problem with this approach?
Thanks!
Francis
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.
That's what we had hoped.
We tested the principle with postgres 7.4.6 but found a what we believe is a
compile time dependancy in create_conversion.sql where $libdir is not being
resolved properly during the initdb process on the second machine. The usual
environment variables don't seem to help (LD_LIBRARY_PATH; PATH; PGLIB etc).
Anyone come across that?
Thx
-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog@svana.org]
Sent: 24 November 2004 13:33
To: Francis Reed
Cc: 'pgsql-general@postgresql.org'
Subject: Re: [GENERAL] Moving/Using Postgres Binaries on multiple
machines
Sure, this is what Linux distributers do. They compile postgresql into
a binary package which is installed on the user's machine.
It works as long as the environments are reasonably compatable, all
have readline, similar libc, etc.
Hope this helps,
On Wed, Nov 24, 2004 at 12:30:28PM -0000, Francis Reed wrote:
If I want to create a postgres database on multiple machines, is the
practice of tarring or zipping up binaries compiled on one machine and
untarring them on another, and using the binaries (initdb etc)
acceptable?.
This removes the need for having a compiler and environment on the target
machine, or is it necessary always to have such an environment on any
machine you intend to use postgres on? Postgres seems to have enough
environment options to allow this to work, overriding the original library
locations and paths etc from the original machine on which postgres was
compiled.Does anyone see a problem with this approach?
Thanks!
Francis
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.
Import Notes
Resolved by subject fallback
Francis Reed <freed@iel.ie> writes:
If I want to create a postgres database on multiple machines, is the
practice of tarring or zipping up binaries compiled on one machine and
untarring them on another, and using the binaries (initdb etc) acceptable?.
This removes the need for having a compiler and environment on the target
machine, or is it necessary always to have such an environment on any
machine you intend to use postgres on? Postgres seems to have enough
environment options to allow this to work, overriding the original library
locations and paths etc from the original machine on which postgres was
compiled.Does anyone see a problem with this approach?
I've had no problems doing this, though I generally standardize the
install location across multiple machines.
-Doug
Francis Reed wrote:
Hi Richard, Sun/Sparc is the platform of choice in our case. We tested the
principle with postgres 7.4.6 but found a what we believe is a compile time
dependancy in create_conversion.sql where $libdir is not being resolved
properly during the intidb process. The usual environment variables don't
seem to help (LD_LIBRARY_PATH; PATH; PGLIB etc). Its not clear whether the
concept of binary distribution is not supported, hence my general question.
Sounds like it should be fine, for your situation*. It could be there is
a glitch in create_conversion.sql, especially if it is something that
won't show if you compile on the machine you want to run on. You might
want to file a bug on it. I'm afraid I don't have a copy of the 7.4.6
tarball to hand.
It might also be worth checking 8.0beta to see if it's fixed there - I
know some relocation changes were made there (because of the Windows
port iirc).
Bit puzzled there isn't some standard binary package already built for
various flavours of Sun box though.
* of course, assuming you're on the same OS version with compatible
libraries etc etc etc.
PS - cc the list and the sender when you reply, it's the convention
round here (though not on most lists I'll grant you)
--
Richard Huxton
Archonet Ltd
Import Notes
Reply to msg id not found: 14F834609826C748873A5012F5C13EAE7EEEF1@dubmail2.iel.ieReference msg id not found: 14F834609826C748873A5012F5C13EAE7EEEF1@dubmail2.iel.ie | Resolved by subject fallback
Francis Reed wrote:
We tested the principle with postgres 7.4.6 but found a what we
believe is a compile time dependancy in create_conversion.sql where
$libdir is not being resolved properly during the initdb process on
the second machine. The usual environment variables don't seem to
help (LD_LIBRARY_PATH; PATH; PGLIB etc). Anyone come across that?
Moving the installation to a different path is not supported for
permanent use before 8.0. You better try to install in the same
directory layout on all machines where you want to deploy.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
Francis Reed wrote:
We tested the principle with postgres 7.4.6 but found a what we
believe is a compile time dependancy in create_conversion.sql where
$libdir is not being resolved properly during the initdb process on
the second machine. The usual environment variables don't seem to
help (LD_LIBRARY_PATH; PATH; PGLIB etc). Anyone come across that?Moving the installation to a different path is not supported for
permanent use before 8.0. You better try to install in the same
directory layout on all machines where you want to deploy.
You can also use links, which is what we do. Mammoth Reokicator
automaticaly install in /usr/local/pgsql but we often put it
in /opt and we just link /usr/local/pgsql back.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
Francis Reed <freed@iel.ie> writes:
We tested the principle with postgres 7.4.6 but found a what we believe is a
compile time dependancy in create_conversion.sql where $libdir is not being
resolved properly during the initdb process on the second machine.
We only started supporting the idea of a relocatable installation for
8.0; in prior versions you can't just arbitrarily install the files
to a different path than what you said at configure time. Even in 8.0
the files have to remain in the same relative locations.
regards, tom lane