Re: easy one: location of the database cluster - Mailing list pgsql-admin

From Iain
Subject Re: easy one: location of the database cluster
Date
Msg-id 00c701c4e3dc$7da40cf0$7201a8c0@mst1x5r347kymb
Whole thread Raw
In response to Re: easy one: location of the database cluster  (<ogjunk-pgjedan@yahoo.com>)
List pgsql-admin
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


pgsql-admin by date:

Previous
From: Mário Gamito
Date:
Subject: chroot PostgreSQL
Next
From: "Iain"
Date:
Subject: archive is compressed - any data will not be available