On Thu, Jan 15, 2026 at 8:57 Amit Langote <[email protected]> wrote:
> On Thu, Jan 15, 2026 at 12:38 AM Tom Lane <[email protected]> wrote: > > Amit Langote <[email protected]> writes: > > > On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <[email protected]> > wrote > > >> Looking at ProcKill, I notice that we do some LWLock ops after its > > >> LWLockReleaseAll() call, which seems a bit silly. Why not do that > right > > >> after the "if (MyProc->lockGroupLeader != NULL)" block instead? > Nothing > > >> uses LWLocks from there on. This can be a separate commit. > > > > > Just to confirm: you're suggesting moving the LWLockReleaseAll() call > > > to after the "if (MyProc->lockGroupLeader != NULL)" block? Makes sense > > > -- odd to release all locks right before then going ahead and > > > acquiring one. Agreed it should be a separate commit. > > > > I think the idea there might be to make sure that we have released > > any pre-existing hold of that lock. Otherwise this could be > > a self-deadlock. > > Hmm, good point. Though with this patch, which adds LWLockReleaseAll() > at the start of shmem_exit(), we would have already released any such > lock before we get to ProcKill(). Scratch that. shmem_exit() is hardly the only caller of ProcKill() and while the existing callers seem to be disciplined, any future callers may not always release locks beforehand. >
