On Wed, Dec 17, 2025 at 19:37 Rahila Syed <rahilasyed90@gmail.com> 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
