Re: Parallel vacuum workers prevent the oldest xmin from advancing

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel vacuum workers prevent the oldest xmin from advancing
Date: 2021-11-11 08:06:31
Message-ID: CAD21AoBvxq6_Je+ipNPBPG1xwKaYbSzWU6zpEpANixFvHxqPwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 11, 2021 at 3:07 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Nov 11, 2021 at 10:40 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Thu, Nov 11, 2021 at 12:53 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Thu, Nov 11, 2021 at 9:11 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 2021-11-11 12:22:42 +0900, Masahiko Sawada wrote:
> > > > > > 2.
> > > > > > LWLockAcquire(ProcArrayLock, LW_SHARED);
> > > > > >
> > > > > > + flags = proc->statusFlags;
> > > > > > +
> > > > > > + /*
> > > > > > + * If the source xact has any statusFlags, we re-grab ProcArrayLock
> > > > > > + * on exclusive mode so we can copy it to MyProc->statusFlags.
> > > > > > + */
> > > > > > + if (flags != 0)
> > > > > > + {
> > > > > > + LWLockRelease(ProcArrayLock);
> > > > > > + LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
> > > > > > + }
> > > > > >
> > > > > >
> > > > > > This looks a bit odd to me. It would have been better if we know when
> > > > > > to acquire an exclusive lock without first acquiring the shared lock.
> > > > >
> > > > > I think we should acquire an exclusive lock only if status flags are
> > > > > not empty. But to check the status flags we need to acquire a shared
> > > > > lock. No?
> > > >
> > > > This seems like an unnecessary optimization. ProcArrayInstallRestoredXmin()
> > > > only happens in the context of much more expensive operations.
> > > >
> > >
> > > Fair point. I think that will also make the change in
> > > ProcArrayInstallRestoredXmin() appear neat.
> >
> > Agreed.
> >
> > This makes me think that it'd be better to copy status flags in a
> > separate function rather than ProcArrayInstallRestoredXmin(). The
> > current patch makes use of the fact that ProcArrayInstallRestoedXmin()
> > acquires a shared lock in order to check the source's status flags.
> > But if we can acquire an exclusive lock unconditionally in this
> > context, it’s clearer to do in a separate function.
> >
>
> Do you mean to say that do it in a separate function and call
> immediately after StartParallelWorkerTransaction or do you mean to do
> it in a separate function and invoke it from
> ProcArrayInstallRestoedXmin()?

I meant the former.

> I think the disadvantage I see by not
> doing in ProcArrayInstallRestoedXmin is that we need to take procarray
> lock twice (once in exclusive mode and then in shared mode) so doing
> it in ProcArrayInstallRestoedXmin is beneficial from that angle.

Right. I thought that this overhead is also negligible in this
context. If that’s right, it’d be better to do it in a separate
function from the clearness point of view. Also if we raise the lock
level in ProcArrayInstallRestoredXmin(), a caller of the function who
wants just to set xmin will end up acquiring an exclusive lock. Which
is unnecessary for the caller.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2021-11-11 08:14:26 Re: Data is copied twice when specifying both child and parent table in publication
Previous Message houzj.fnst@fujitsu.com 2021-11-11 06:52:40 RE: Data is copied twice when specifying both child and parent table in publication