Josh Berkus <j...@agliodbs.com> writes: > On 09/29/2015 11:48 AM, Tom Lane wrote: >> But today I thought of another way: suppose that we teach the postmaster >> to commit hara-kiri if the $PGDATA directory goes away. Since the >> buildfarm script definitely does remove all the temporary data directories >> it creates, this ought to get the job done.
> This would also be useful for production. I can't count the number of > times I've accidentally blown away a replica's PGDATA without shutting > the postmaster down first, and then had to do a bunch of kill -9. > In general, having the postmaster survive deletion of PGDATA is > suboptimal. In rare cases of having it survive installation of a new > PGDATA (via PITR restore, for example), I've even seen the zombie > postmaster corrupt the data files. Side comment on that: if you'd actually removed $PGDATA, I can't see how that would happen. The postmaster and children would have open CWD handles to the now-disconnected-from-anything-else directory inode, which would not enable them to reach files created under the new directory inode. (They don't ever use absolute paths, only relative, or at least that's the way it's supposed to work.) However ... if you'd simply deleted everything *under* $PGDATA but not that directory itself, then this type of failure mode is 100% plausible. And that's not an unreasonable thing to do, especially if you've set things up so that $PGDATA's parent is not a writable directory. Testing accessibility of "global/pg_control" would be enough to catch this case, but only if we do it before you create a new one. So that seems like an argument for making the test relatively often. The once-a-minute option is sounding better and better. We could possibly add additional checks, like trying to verify that pg_control has the same inode number it used to. But I'm afraid that would add portability issues and false-positive hazards that would outweigh the value. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers