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 |
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 |