Re: Segmentation fault on proc exit after dshash_find_or_insert

Álvaro Herrera <alvherre@kurilemu.de>

From: Álvaro Herrera <alvherre@kurilemu.de>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Rahila Syed <rahilasyed90@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-01-14T09:36:24Z
Lists: pgsql-hackers
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.  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).

Are you going to push this soon?

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.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/



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