Re: Segmentation fault on proc exit after dshash_find_or_insert

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Rahila Syed <rahilasyed90(at)gmail(dot)com>
Cc: 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: 2025-12-17 08:25:41
Message-ID: CA+HiwqFjxVrRCQ2PDeFLMZswg1=NSOhgPTrNv7S4FeUXW-X-YA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Rahila,

On Wed, Dec 17, 2025 at 3:57 PM Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:
>
> Hi Amit,
>
>
>>
>> Oops, forgot an #include. Fixed in the attached.
>>
>
> Thank you for the updated patch and the detailed commit message. You have explained the problem
> quite well and the changes look good to me.

Thanks for looking.

> I would just add one more comment, which I have attached as a separate patch with this email.
> Please have a look.

/*
* Release any LWLocks we might be holding, before running callbacks that
- * may detach the memory containing those locks.
+ * may detach the memory containing those locks. Releasing all the locks
+ * ensures that any callbacks executed afterward will be able to acquire
+ * any lock.
*/

Hmm, I'm not sure I follow. Maybe it has to do with something you
were trying to do when you ran into this bug, but why would callbacks
be acquiring locks after an error and why would it be safe to do so?
Are you saying that LWLockReleaseAll() cleans up unsafe-to-access
locks so that new ones can be taken after that point?

--
Thanks, Amit Langote

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-12-17 08:32:09 DOC: Fix formatting of ALTER TABLE REPLICA IDENTITY documentation
Previous Message Michael Paquier 2025-12-17 08:19:33 Re: Fix and improve allocation formulas