Re: Segmentation fault on proc exit after dshash_find_or_insert - Mailing list pgsql-hackers

From Rahila Syed
Subject Re: Segmentation fault on proc exit after dshash_find_or_insert
Date
Msg-id CAH2L28to0CbBWeSKvinp6wFrwX-ZBMqbGQ3_1Bkyits+yn_w_Q@mail.gmail.com
Whole thread Raw
In response to Re: Segmentation fault on proc exit after dshash_find_or_insert  (Amit Langote <amitlangote09@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Improve pg_sync_replication_slots() to wait for primary to advance
Next
From: Peter Eisentraut
Date:
Subject: Re: Remaining dependency on setlocale()