Feedback-ID: ie3de48e3:Fastmail
Date: Wed, 14 Jan 2026 10:36:24 +0100
From: =?utf-8?Q?=C3=81lvaro?= 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>
Subject: Re: Segmentation fault on proc exit after dshash_find_or_insert
Message-ID: <202601140928.sbxjiuhq5ae6@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+HiwqHzTpLH9q3XHSiXndCgVYi8CvaeOcMgu7ZoYS2XOYqtiA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202601140928.sbxjiuhq5ae6%40alvherre.pgsql>
Precedence: bulk

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/