Tom Lane wrote:
We've seen more than one report of corruption of PG databases that
seemed to be due to the willingness of the RPM init script to run
initdb if it thinks the data directory isn't there. This is pretty
darn risky on an NFS volume, for instance, which might be offline
at the instant the script looks. The failure case is
- script doesn't see data directory
- script runs initdb and starts postmaster
- offline volume comes online
- KABOOM
Been there, done exactly that...
I can still imagine ways for this to fail, eg if you run an RPM
install or upgrade while your mountable data directory is offline.
But it ought to be an order of magnitude safer than things are now.
(Hm, maybe the %post script should only run during an RPM install,
not an upgrade.)
That's probably a good plan.
Comments? Anyone see a better way?
I can't think of any offhand that aren't too expensive. We ended up
putting a root-owned empty data directory beneath the mount point, but
that can't be automated.
We also decided to turn off the init script execution entirely. The DBAs
were more comfortable with a manual database startup for a production
machine anyway (this is the way they typically handle Oracle databases
also). They get paged if the server ever goes down unplanned, and in
that event they like to check things out before bringing the db back up.
For planned outages, database startup is simply part of the plan.
Joe
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
