Re: Segmentation fault on proc exit after dshash_find_or_insert

amit <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Rahila Syed <rahilasyed90@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-01-14T13:56:36Z
Lists: pgsql-hackers
Hi Alvaro,

On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <alvherre@kurilemu.de> wrote
> On 2025-Dec-18, Amit Langote wrote:
>
> > Thanks.  Updated the commit message too to be more accurate in the
> > attached updated patch.
>
> Looks good to me.

Thanks for looking.

> I would add an Assert(num_held_lwlocks == 0) at the
> end of LWLockReleaseAll(), to make it clear that it's idempotent (which
> is important for the case where ProcKill will call it again shortly
> after).

Makes sense.  Will do.

> Are you going to push this soon?

Yes, I will try tomorrow.

> 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.

-- 
Thanks, Amit Langote



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix segfault from releasing locks in detached DSM segments