Thread: 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/ > 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.
Attachment
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/ > 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.
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
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
Attachment
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