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 →
-
Fix segfault from releasing locks in detached DSM segments
- f6df78173ef5 14.21 landed
- b926ff1373bb 15.16 landed
- 980b7c7369e4 16.12 landed
- 4071fe900e67 17.8 landed
- 1943ceb38842 18.2 landed
- 9cbb1d21d67e 19 (unreleased) landed