Subject: Re: Segmentation fault on proc exit after dshash_find_or_insert

From: Amit Langote <[email-masked]>
Date: Thu, 15 Jan 2026 09:12:35 +0900

On Thu, Jan 15, 2026 at 8:57 Amit Langote <[email-masked]> wrote:

> On Thu, Jan 15, 2026 at 12:38 AM Tom Lane <[email-masked]> wrote:
> > Amit Langote <[email-masked]> writes:
> > > On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <[email-masked]>
> wrote
> > >> Looking at ProcKill, I notice that we do some LWLock ops after its
> > >> LWLockReleaseAll() call, which seems a bit silly.  Why not do that
> right
> > >> after the "if (MyProc->lockGroupLeader != NULL)" block instead?
> Nothing
> > >> uses LWLocks from there on.  This can be a separate commit.
> >
> > > Just to confirm: you're suggesting moving the LWLockReleaseAll() call
> > > to after the "if (MyProc->lockGroupLeader != NULL)" block? Makes sense
> > > -- odd to release all locks right before then going ahead and
> > > acquiring one. Agreed it should be a separate commit.
> >
> > I think the idea there might be to make sure that we have released
> > any pre-existing hold of that lock.  Otherwise this could be
> > a self-deadlock.
>
> Hmm, good point. Though with this patch, which adds LWLockReleaseAll()
> at the start of shmem_exit(), we would have already released any such
> lock before we get to ProcKill().

Scratch that. shmem_exit() is hardly the only caller of ProcKill() and
while the existing callers seem to be disciplined, any future callers may
not always release locks beforehand.