Re: DSM robustness failure (was Re: Peripatus/failures) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: DSM robustness failure (was Re: Peripatus/failures)
Date
Msg-id CAEepm=21SZdv0m_z5x0WnoKNjdBmwF6VhY3bN3L-RkTtgT6bxw@mail.gmail.com
Whole thread Raw
In response to Re: DSM robustness failure (was Re: Peripatus/failures)  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: DSM robustness failure (was Re: Peripatus/failures)  (Larry Rosenman <ler@lerctr.org>)
Re: DSM robustness failure (was Re: Peripatus/failures)  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
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.

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

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pg_stat_ssl additions
Next
From: Andrew Dunstan
Date:
Subject: Re: MSVC compilers complain about snprintf