Re: Segmentation fault on proc exit after dshash_find_or_insert - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Segmentation fault on proc exit after dshash_find_or_insert
Date
Msg-id CA+HiwqGzfwyYc3+tDqucYyMOS_Z6eGpYmAwfB284v1dMf+tN7A@mail.gmail.com
Whole thread Raw
In response to Re: Segmentation fault on proc exit after dshash_find_or_insert  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Segmentation fault on proc exit after dshash_find_or_insert
List pgsql-hackers
On Thu, Jan 15, 2026 at 12:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <amitlangote09@gmail.com> writes:
> > On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <alvherre@kurilemu.de> 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(). But, probably best to leave
ProcKill() alone given this subtlety.

--
Thanks, Amit Langote



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Next
From: Chao Li
Date:
Subject: Re: Refactor replication origin state reset helpers