Hi All,

I'm in the process of putting together some docs for a new postgres server.
For development use, I've always just been content to have the PGDATA
directory as a subdirectory of the main postgres install directory which is
/usr/local/pgsql/ by default (when installing from source anyway).

My question is whether there is any good reason not to do that in a
production environment (for example upgrade time)?

Is there a "standard" directory that people tend to use for this, such as
/var/local/pgsql/ ?

Even if there are no standards, I do like to follow conventions where they
exist, since I don't expect to be around by the time this system will be
requiring it's first round of maintenance ;-)

OS is (will most probably be) RHEL3

Cheers
Iain


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Iain wrote:
> Is there a "standard" directory that people tend to use for this,
> such as /var/local/pgsql/ ?

According to the Filesystem Hierarchy Standard, program data should be
under /var/lib/<packagename>. Indeed, many binary distributions use
some variant of that as data directory location.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Peter Eisentraut <peter_e@gmx.net> writes:
> Iain wrote:
>> Is there a "standard" directory that people tend to use for this,
>> such as /var/local/pgsql/ ?

> According to the Filesystem Hierarchy Standard, program data should be
> under /var/lib/<packagename>. Indeed, many binary distributions use
> some variant of that as data directory location.

The RPM distributions of PG use /var/lib/pgsql/data as the standard
PGDATA value. I'm not sure what Debian does but I think it might be
different. Also there has been some talk of including the major
release number (7.4, 8.0, etc) in the standard PGDATA value, to ease
migration across server versions by allowing different versions to be
installed concurrently.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > Iain wrote:
> >> Is there a "standard" directory that people tend to use for this,
> >> such as /var/local/pgsql/ ?
>
> > According to the Filesystem Hierarchy Standard, program data should
> be
> > under /var/lib/<packagename>. Indeed, many binary distributions
> use
> > some variant of that as data directory location.
>
> The RPM distributions of PG use /var/lib/pgsql/data as the standard
> PGDATA value. I'm not sure what Debian does but I think it might be
> different. Also there has been some talk of including the major
> release number (7.4, 8.0, etc) in the standard PGDATA value, to ease
> migration across server versions by allowing different versions to be
> installed concurrently.

Oh, this would be excellent! The fear of dealing with 2 different
versions and the fear of overwriting something by mistake is what's
keeping me from upgrading my PG installation.

Otis

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Hi,

Looks like I should get to know the "Filesystem Hierarchy Standard" atleast
a little better.

>> The RPM distributions of PG use /var/lib/pgsql/data as the standard
>> PGDATA value. I'm not sure what Debian does but I think it might be
>> different. Also there has been some talk of including the major
>> release number (7.4, 8.0, etc) in the standard PGDATA value, to ease
>> migration across server versions by allowing different versions to be
>> installed concurrently.
>
> Oh, this would be excellent! The fear of dealing with 2 different
> versions and the fear of overwriting something by mistake is what's
> keeping me from upgrading my PG installation.

This is partly my concern also. It's only a concern for me because I don't
have any direct experience of managing and upgrading production systems
using packages, I have always used the source code download. Backing up your
databases before an upgrade is always advisable, but on the other hand, we
typically don't want to have to endure a restore just because we messed up a
minor upgrade. if you are building from source it's no problem as you just
don't run initdb. As to package upgrades, presumably they don't touch your
data. I have to write a manual for the maintenance and updating of the
server, so I'm gonna have to test it all anyway.

Getting back to my original question (as I think it was) I havn't seen any
reason not to use the default data directory used by the package, especially
if it conforms with the above mentioned standard.

Regards
Iain


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match