On Tue, Oct 08, 2013 at 03:40:04PM -0400, Robert Haas wrote: > On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch <n...@leadboat.com> wrote:
> >> > "There's no data corruption problem if we proceed" - but there likely > >> > has been one leading to the current state. > > > > +1 for making this one a PANIC, though. With startup behind us, a valid dsm > > state file pointed us to a control segment with bogus contents. The > > conditional probability of shared memory corruption seems higher than that > > of > > a DBA editing the dsm state file of a running cluster to incorrectly name as > > the dsm control segment some other existing shared memory segment. > > To respond specifically to this point... inability to open a file on > disk does not mean that shared memory is corrupted. Full stop. > > A scenario I have seen a few times is that someone changes the > permissions on part or all of $PGDATA while the server is running. I was discussing the third ereport() in dsm_backend_startup(), which does not pertain to inability to open a file. The second ereport() would fire in the damaged-permissions scenario, and I fully agree with that one using ERROR. Incidentally, dsm_backend_startup() has a typo: s/"one/"none/ > I am tempted to commit the latest version of this patch as I have it. Works for me. Thanks, nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
