On Mon, Jan 30, 2023 at 9:41 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Mon, Jan 30, 2023 at 8:30 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, Jan 27, 2023 at 4:31 PM Hayato Kuroda (Fujitsu) > > <kuroda.hay...@fujitsu.com> wrote: > > > > > > Thank you for making the patch! I'm still considering whether this > > > approach is > > > correct, but I can put a comment to your patch anyway. > > > > > > ``` > > > - Assert(!already_locked || LWLockHeldByMe(ProcArrayLock)); > > > - > > > - if (!already_locked) > > > - LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > > > + Assert(LWLockHeldByMe(ProcArrayLock)); > > > ``` > > > > > > In this function, we regard that the ProcArrayLock has been already > > > acquired as > > > exclusive mode and modify data. I think LWLockHeldByMeInMode() should be > > > used > > > instead of LWLockHeldByMe(). > > > > > > > Right, this is even evident from the comments atop > > ReplicationSlotsComputeRequiredXmin("If already_locked is true, > > ProcArrayLock has already been acquired exclusively.". > > Agreed, will fix in the next version patch. > > > But, I am not > > sure if it is a good idea to remove 'already_locked' parameter, > > especially in back branches as this is an exposed API. > > Yes, we should not remove the already_locked parameter in > backbranches. So I was thinking of keeping it on back branches. >
I've attached patches for HEAD and backbranches. Please review them. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
master_v2-0001-Fix-a-race-condition-of-updating-procArray-replic.patch
Description: Binary data
REL13-14_v2-0001-Fix-a-race-condition-of-updating-procArray-replic.patch
Description: Binary data
REL15_v2-0001-Fix-a-race-condition-of-updating-procArray-replic.patch
Description: Binary data
REL11-12_v2-0001-Fix-a-race-condition-of-updating-procArray-replic.patch
Description: Binary data