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
stuckbecause waiting all parallel workers, but one worker has unexpected recursion in dsm_backend_shutdown [1] and will
nevershutdown. Backtrace show previous error in this backend: "cannot unpin a segment that is not pinned" - root cause
isearlier 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
