Re: what happend to my database - Mailing list pgsql-admin

From Medi Montaseri
Subject Re: what happend to my database
Date
Msg-id 8078a1730805282214l32d4833j50ccb6c5bb177c9a@mail.gmail.com
Whole thread Raw
In response to Re: what happend to my database  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: what happend to my database
List pgsql-admin
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 <tgl@sss.pgh.pa.us> wrote:
Steve Holdoway <steve.holdoway@firetrust.com> writes:
> "Medi Montaseri" <montaseri@gmail.com> 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

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: what happend to my database
Next
From: Karen Stone
Date:
Subject: statistics collector Log message