Re: Assertion failure in SnapBuildInitialSnapshot()

On Mon, Jan 30, 2023 at 9:41 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Mon, Jan 30, 2023 at 8:30 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Jan 27, 2023 at 4:31 PM Hayato Kuroda (Fujitsu)
> > <kuroda.hayato@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