| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg11.1: dsa_area could not attach to segment |
| Date: | 2019-02-14 16:20:10 |
| Message-ID: | 20190214162010.GM30291@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 15, 2019 at 01:12:35AM +1300, Thomas Munro wrote:
> The problem is that a DSM handle (ie a random number) can be reused
> for a new segment immediately after the shared memory object has been
> destroyed but before the DSM slot has been released. Now two DSM
> slots have the same handle, and dsm_attach() can be confused by the
> old segment and give up.
>
> Here's a draft patch to fix that. It also clears the handle in a case
> where it wasn't previously cleared, but that wasn't strictly
> necessary. It just made debugging less confusing.
Thanks.
Do you think that plausibly explains and resolves symptoms of bug#15585, too?
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergei Kornilov | 2019-02-14 16:36:55 | Re: pg11.1: dsa_area could not attach to segment |
| Previous Message | Andres Freund | 2019-02-14 16:14:34 | Re: WAL insert delay settings |