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

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Larry Rosenman <ler(at)lerctr(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: DSM robustness failure (was Re: Peripatus/failures)
Date: 2018-10-17 22:08:33
Message-ID: CAEepm=21SZdv0m_z5x0WnoKNjdBmwF6VhY3bN3L-RkTtgT6bxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 18, 2018 at 9:43 AM Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Thu, Oct 18, 2018 at 9:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 Content-Type Size
0001-Fix-thinko-in-DSM-control-segment-crash-restart-logi.patch application/octet-stream 2.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-10-17 22:09:07 Re: MSVC compilers complain about snprintf
Previous Message Peter Eisentraut 2018-10-17 22:05:15 pg_stat_ssl additions