Re: [GENERAL] Customize the install directory of the postgres DB
Hi all, Thanks for the suggestion, i have tried out the option Thomas has mentioned by unzipping the db, and it works in our scenario. Just a question regarding the shared library. I have run the following command so that postgres can locate the shared library /sbin/ldconfig /home/app/pgsql/lib Below is the result after i executed it, are the following message expected? will it cause any issue on the postgres db? */sbin/ldconfig: /home/app/pgsql/lib/libpgtypes.so.3 is not a symbolic link /sbin/ldconfig: /home/app/pgsql/lib/libuuid.so.16 is not a symbolic link /sbin/ldconfig: /home/app/pgsql/lib/libpq.so.5 is not a symbolic link /sbin/ldconfig: /home/app/pgsql/lib/libecpg.so.6 is not a symbolic link /sbin/ldconfig: /home/app/pgsql/lib/libecpg_compat.so.3 is not a symbolic link * Thanks again. Wei Xiang On Sat, Nov 14, 2009 at 7:10 AM, Greg Smith g...@2ndquadrant.com wrote: Tom Lane wrote: The real problem that I think the OP hasn't considered is whether his bundled RPM package isn't going to conflict with a preinstalled postgresql RPM. Relocating the RPM, either dynamically as you suggest or by just changing the install paths while building it, isn't a very palatable solution since e.g. you really want libpq.so in /usr/lib, psql in /usr/bin/, etc. It sounds like they really do want all of those things to be installed in a subdirectory of their app, so I don't see a problem with them being there instead of the standard locations. As long as they know how to run psql etc., not having them in the global PATH might be a feature rather than a problem. The only detail I'm aware of they may not have considered is that a subdirectory install has the potential for the binaries to not be able to find their associated libraries, so they might either have to add those to the system loader configuration or set LD_LIBRARY_PATH before calling database binaries. Ideally you'd find them via rpath or something so this isn't an issue, but it's easy to miss that the first time you make a change like this. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com
Re: [GENERAL] Customize the install directory of the postgres DB
Greg Smith g...@2ndquadrant.com wrote in message news:4afde758.1050...@2ndquadrant.com... Tom Lane wrote: The real problem that I think the OP hasn't considered is whether his bundled RPM package isn't going to conflict with a preinstalled postgresql RPM. Relocating the RPM, either dynamically as you suggest or by just changing the install paths while building it, isn't a very palatable solution since e.g. you really want libpq.so in /usr/lib, psql in /usr/bin/, etc. It sounds like they really do want all of those things to be installed in a subdirectory of their app, so I don't see a problem with them being there instead of the standard locations. As long as they know how to run psql etc., not having them in the global PATH might be a feature rather than a problem. The only detail I'm aware of they may not have considered is that a subdirectory install has the potential for the binaries to not be able to find their associated libraries, so they might either have to add those to the system loader configuration or set LD_LIBRARY_PATH before calling database binaries. Ideally you'd find them via rpath or something so this isn't an issue, but it's easy to miss that the first time you make a change like this. We started out using pre-built PG group RPMs, then we went to building from src and custom built source RPMs (based on the PG group ones), changing the spec a bit, and finally settling on tar balling the PG install. We install everything under one common directory db under our applications home directory. We create a softlink to point to a directory for specific PG version (easier for migrations required for PG upgrades) ls -l db total 28 drwxrwxr-x 3 root dtm 4096 Nov 14 04:49 . drwxrwxr-x 16 root dtm 4096 Nov 13 23:05 .. lrwxrwxrwx 1 postgres postgres 29 Nov 14 04:49 pgsql - /usr/signiant/dds/db/pgsql_81 drwxr-xr-x 10 postgres postgres 4096 Oct 23 11:08 pgsql_81 Everything goes into the specific PG version directory; ls -l total 80 drwxr-xr-x 10 postgres postgres 4096 Oct 23 11:08 . drwxrwxr-x 3 root dtm 4096 Nov 14 04:49 .. drwxr-xr-x 2 postgres postgres 4096 Jul 10 13:59 bin drwxr-xr-x 2 postgres postgres 4096 Nov 12 14:47 conf drwx-- 10 postgres postgres 4096 Nov 14 04:54 data drwxr-xr-x 3 postgres postgres 4096 Jul 10 13:59 doc drwxr-xr-x 6 postgres postgres 4096 Jul 10 13:59 include drwxr-xr-x 3 postgres postgres 4096 Jul 10 13:59 lib drwxr-xr-x 4 postgres postgres 4096 Jul 10 13:59 man drwxr-xr-x 3 postgres postgres 4096 Jul 10 13:59 share To handle the shared libraries issues we build our apps (and PG) to look for the PG shared libraries in a specific location /usr/ddspostgres which our installer creates a soft link to the specific version ls -l /usr/ddspost* lrwxrwxrwx 1 root root 29 Nov 14 04:49 /usr/ddspostgres - /usr/signiant/dds/db/pgsql_81 ldd on the psql we build looks for the shared library in /usr/dds/postgres; ldd psql libpq.so.4 = /usr/ddspostgres/lib/libpq.so.4 (0x2aaad000) libz.so.1 = /usr/lib64/libz.so.1 (0x0032b740) libreadline.so.5 = /usr/lib64/libreadline.so.5 (0x2acd2000) libtermcap.so.2 = /lib64/libtermcap.so.2 (0x0032b700) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x0032b840) libresolv.so.2 = /lib64/libresolv.so.2 (0x0032b980) libnsl.so.1 = /lib64/libnsl.so.1 (0x0032b800) libdl.so.2 = /lib64/libdl.so.2 (0x0032b5c0) libm.so.6 = /lib64/libm.so.6 (0x0032b600) libc.so.6 = /lib64/libc.so.6 (0x0032b580) /lib64/ld-linux-x86-64.so.2 (0x0032b540) Our app thens to run on a server by itself in the wild, but we have run into a few installs with conflicts with pre-installed PostgreSQL, and issues with using /usr/bin/psql instead of the psql utility in our install in certain scripts. We have not yet had to run on a seperate port (that I am aware of), we still use the default port so we really haven't run into installs that required running two versions of PostgreSQL on the same server at the same time. Eric -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Customize the install directory of the postgres DB
weixiang tam wrote: I am trying to install the postgres8.2.14 via the RPM; however the install directory is default to the following folder * Executables : /usr/bin * Libraries : /usr/lib * Documentation : /usr/share/doc/postgresql-x.y.z , /usr/share/doc/postgresql-x.y.z/contrib * Contrib : /usr/share/pgsql/contrib * Data : /var/lib/pgsql/data As we are bundling the postgresql db as our product release, we would like to keep the Postgres executable dir, Data Dir under our product folder. In this case, could I know whether I can customize the install directory when i do the RPM installation? If you mean the RPMs PostgreSQL provides, no. What I would recommend is to take the source RPM, change the spec in those places where these directories are defined, and build your own RPM. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Customize the install directory of the postgres DB
weixiang tam wrote: As we are bundling the postgresql db as our product release, we would like to keep the Postgres executable dir, Data Dir under our product folder. In this case, could I know whether I can customize the install directory when i do the RPM installation? What you'd probably like to have here is what's called a relocatable RPM. The RPMs provided for PostgreSQL are not relocatable. There's an intro to how to restructure and rebuild a RPM to make it relocatable at http://rpm.org/max-rpm/s1-rpm-reloc-building-relocatable.html ; it will take several hours of work (most of which are spent waiting for PostgreSQL to compile while re-testing) in order to do something similar to the PostgreSQL RPMs. It's painful enough you may just settle for a RPM that gets built with the directory of your application passed in instead, which reduces the trouble a bit (but not completely). -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Customize the install directory of the postgres DB
Greg Smith g...@2ndquadrant.com writes: weixiang tam wrote: As we are bundling the postgresql db as our product release, we would like to keep the Postgres executable dir, Data Dir under our product folder. In this case, could I know whether I can customize the install directory when i do the RPM installation? What you'd probably like to have here is what's called a relocatable RPM. The RPMs provided for PostgreSQL are not relocatable. Moving the data directory is not that hard, you just need to add a config file that changes the PGDATA value seen by the init script. The real problem that I think the OP hasn't considered is whether his bundled RPM package isn't going to conflict with a preinstalled postgresql RPM. Relocating the RPM, either dynamically as you suggest or by just changing the install paths while building it, isn't a very palatable solution since e.g. you really want libpq.so in /usr/lib, psql in /usr/bin/, etc. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Customize the install directory of the postgres DB
weixiang tam wrote on 13.11.2009 10:16: Dear all, I am trying to install the postgres8.2.14 via the RPM; however the install directory is default to the following folder * Executables : /usr/bin * Libraries : /usr/lib * Documentation : /usr/share/doc/postgresql-x.y.z , /usr/share/doc/postgresql-x.y.z/contrib * Contrib : /usr/share/pgsql/contrib * Data : /var/lib/pgsql/data As we are bundling the postgresql db as our product release, we would like to keep the Postgres executable dir, Data Dir under our product folder. In this case, could I know whether I can customize the install directory when i do the RPM installation? Why don't you use the archive binaries from EnterpriseDB? http://www.enterprisedb.com/products/pgbindownload.do I use the ZIP Version on Windows to package Postgresql without problems. I just unzip the archive, run initdb pointing to a directory which is located next to the directory where I unpack the archive. I then use batch files to start and stop the PG server during startup of my (web) application Regards Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Customize the install directory of the postgres DB
Tom Lane wrote: The real problem that I think the OP hasn't considered is whether his bundled RPM package isn't going to conflict with a preinstalled postgresql RPM. Relocating the RPM, either dynamically as you suggest or by just changing the install paths while building it, isn't a very palatable solution since e.g. you really want libpq.so in /usr/lib, psql in /usr/bin/, etc. It sounds like they really do want all of those things to be installed in a subdirectory of their app, so I don't see a problem with them being there instead of the standard locations. As long as they know how to run psql etc., not having them in the global PATH might be a feature rather than a problem. The only detail I'm aware of they may not have considered is that a subdirectory install has the potential for the binaries to not be able to find their associated libraries, so they might either have to add those to the system loader configuration or set LD_LIBRARY_PATH before calling database binaries. Ideally you'd find them via rpath or something so this isn't an issue, but it's easy to miss that the first time you make a change like this. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
