On Tue, Oct 08, 2013 at 03:40:04PM -0400, Robert Haas wrote:
> On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch <noah@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
