Re: DSM robustness failure (was Re: Peripatus/failures)

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Larry Rosenman <ler@lerctr.org>, Pg Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>

Date: 2018-10-18T01:00:11Z

Lists: pgsql-hackers

Attachments

0001-Fix-thinko-in-handling-of-corrupted-DSM-control-area.patch (application/octet-stream) patch 0001

On Thu, Oct 18, 2018 at 11:08 AM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, Oct 18, 2018 at 9:43 AM Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > On Thu, Oct 18, 2018 at 9:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > I would argue that both dsm_postmaster_shutdown and dsm_postmaster_startup
> > > are broken here; the former because it makes no attempt to unmap
> > > the old control segment (which it oughta be able to do no matter how badly
> > > broken the contents are), and the latter because it should not let
> > > garbage old state prevent it from establishing a valid new segment.
> >
> > Looking.
>
> (CCing Amit Kapila)
>
> To reproduce this, I attached lldb to a backend and did "mem write
> &dsm_control->magic 42", and then delivered SIGKILL to the backend.
> Here's one way to fix it.  I think we have no choice but to leak the
> referenced segments, but we can free the control segment.  See
> comments in the attached patch for rationale.

I realised that the nearly identical code in dsm_postmaster_shutdown()
might as well destroy a corrupted control segment too.  New version
attached.

-- 
Thomas Munro
http://www.enterprisedb.com