On Wed, Dec 17, 2025 at 19:37 Rahila Syed <[email protected]> wrote: > 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.
I get confused easily it seems. :-) You’re right, this is how I understood it too the last time we were here, but I remembered something Andres wrote upthread and interpreted it wrongly in my head. Also, now that I read the full comment, the first sentence doesn’t look quite right; callbacks don’t detach segments. How about rewording the comment a bit, like this: /* * Release any LWLocks we might be holding before callbacks run. This * prevents accessing locks in detached DSM segments and allows callbacks * to acquire new locks. */ -- Thanks, Amit Langote
