Re: Segmentation fault on proc exit after dshash_find_or_insert

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Rahila Syed <rahilasyed90(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Segmentation fault on proc exit after dshash_find_or_insert
Date: 2026-01-14 13:56:36
Message-ID: CA+HiwqG7uO2+c0AV8CWt7qG1izzN3PjdKDtgMqK9a0tiNvzHnw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alvaro,

On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <alvherre(at)kurilemu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2026-01-14 14:17:22 Re: Buffer locking is special (hints, checksums, AIO writes)
Previous Message Andres Freund 2026-01-14 13:32:36 Re: Enhancing Memory Context Statistics Reporting