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

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 Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com

Greg Smith <greg@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

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

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 Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com

"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

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 <greg@2ndquadrant.com> wrote: