Yes, this type of presumptuous behavior to wipe out a production database based on a few checks is too risky...
Behavior one: First out-of-box time, pg_ctl does not find any database files, it tells the user that "sorry I did not find any database to start....see initdb.... Result: we have a semi-unhappy user/admin that says... what is initdb Behavior two: In order to enhance the out-of-box experience, we have wiped out a production environment, leading to many unhappy staff and customers.... PG developers...I am not impressed at all... Medi On Wed, May 28, 2008 at 7:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Steve Holdoway <[EMAIL PROTECTED]> writes: > > "Medi Montaseri" <[EMAIL PROTECTED]> wrote: > >> I think the following happend... > >> Since my PGDATA was on an iSCSI device, by the time > /etc/rc3.d/S64postgresql > >> was executed, the device below it was not available.....question...why > the > >> error says "permission denied" vs "file not found". In the meantime, > pg_ctl > >> kept trying and finally concluded that the data directory is blank, and > >> hence this must be a out-of-box case and he is good to initdb the PGDATA > and > >> as it called initdb to do the job... the iSCSI volume below it came > online > >> and by then the bomb had already been dropped. > >> > >> Now I need to find some facts to support this... > > When you mount a partition on linux, it does this by overlaying it's root > directory with the existing one on the parent volume. Ownerships and > permissions are also replaced. I expect that the /qmsvol directory will be > owned by root, with fairly restrictive access rights. This will not be the > case the root ( . ) directory on the external device, which will be > postgres-friendly. > >> Where else can I look for forensics > > I don't think you need any more! To fix this, I'd do 2 things. First, > start postgres much later in the boot sequence: > > cd /etc/rc3.d ; mv S64postgresql S99postgresql > > ( and the same in rc5.d if you're using a gui at all ). > > The other thing to do is remove the auto-initdb behavior in your startup > script. We've done that in recent releases because of prior reports of > this type of problem. The OP's script is evidently still old-school, > though. > > regards, tom lane > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin >
