Re: pg11.1: dsa_area could not attach to segment

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Sergei Kornilov <sk@zsrv.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-14T21:00:12Z
Lists: pgsql-hackers
On Fri, Feb 15, 2019 at 5:36 AM Sergei Kornilov <sk@zsrv.org> wrote:
> > Do you think that plausibly explains and resolves symptoms of bug#15585, too?
>
> I think yes. Bug#15585 raised only after "dsa_area could not attach to segment" in different parallel worker. Leader stuck because waiting all parallel workers, but one worker has unexpected recursion in dsm_backend_shutdown [1] and will never shutdown. Backtrace show previous error in this backend: "cannot unpin a segment that is not pinned" - root cause is earlier and in a different process.

Agreed.  Even though it's an unpleasant failure mode, I'm not entirely
sure if it's a good idea to make changes to avoid it.  We could move
the code around so that the error is raised after releasing the lock,
but then you'd either blow the stack or loop forever due to longjmp (I
haven't checked which).  To avoid that you'd have to clean out the
book-keeping in shared memory eagerly so that at the next level of
error recursion you've at least made progress (and admittedly there
are examples of things like that in the code), but how far should we
go to tolerate cases that shouldn't happen?  Practically, if we had
that behaviour and this bug, you'd eventually eat all the DSM slots
with leaked segments of shared memory, and your system wouldn't work
too well.  For now I think it's better to treat the root cause of the
unexpected error.

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


Commits

  1. Fix race in dsm_attach() when handles are reused.

  2. Refactor pid, random seed and start time initialization.