Re: Segmentation fault on proc exit after dshash_find_or_insert

Rahila Syed <rahilasyed90@gmail.com>

From: Rahila Syed <rahilasyed90@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-12-17T10:36:58Z
Lists: pgsql-hackers
Hi Amit,


>      /*
>       * 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?
>

It seems common for both before and on shmem exit callbacks to acquire
locks.
For instance, RemoveTempRelationsCallback eventually calls performDeletion,
which acquires an LW lock.


> Are you saying that LWLockReleaseAll() cleans up unsafe-to-access
> locks so that new ones can be taken after that point?
>

Yes, what I mean is that acquiring a lock within a callback will work,
regardless of whether it was held when the error occurred, since we ensure
all locks are released before executing the callbacks.

Thank you,
Rahila Syed