On 09/29/2015 12:47 PM, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> 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.
>
> 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.
I don't remember the exact setup, but this is likely the case. Probably
1/3 of the systems I monitor have a root-owned mount point for PGDATA's
parent 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.
It's not worth doing extra stuff for this.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
