Re: Customize the install directory of the postgres DB - Mailing list pgsql-general

"Greg Smith" <greg@2ndquadrant.com> wrote in message
news:4AFDE758.1050400@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 (0x00002aaaaaaad000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00000032b7400000)
        libreadline.so.5 => /usr/lib64/libreadline.so.5 (0x00002aaaaacd2000)
        libtermcap.so.2 => /lib64/libtermcap.so.2 (0x00000032b7000000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000032b8400000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00000032b9800000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00000032b8000000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000032b5c00000)
        libm.so.6 => /lib64/libm.so.6 (0x00000032b6000000)
        libc.so.6 => /lib64/libc.so.6 (0x00000032b5800000)
        /lib64/ld-linux-x86-64.so.2 (0x00000032b5400000)


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