Horton
Menu

Re: Segmentation fault on proc exit after dshash_find_or_insert

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Rahila Syed <rahilasyed90@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-01-14T15:38:00Z
Lists: pgsql-hackers 
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.

			regards, tom lane

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