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