Re: Parallel vacuum workers prevent the oldest xmin from advancing

On Sat, Oct 9, 2021 at 12:13 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2021-Oct-06, Masahiko Sawada wrote:
>
> > Hi all,
> >
> > A customer reported that during parallel index vacuum, the oldest xmin
> > doesn't advance. Normally, the calculation of oldest xmin
> > (ComputeXidHorizons()) ignores xmin/xid of processes having
> > PROC_IN_VACUUM flag in MyProc->statusFlags. But since parallel vacuum
> > workers don’t set their statusFlags, the xmin of the parallel vacuum
> > worker is considered to calculate the oldest xmin. This issue happens
> > from PG13 where the parallel vacuum was introduced. I think it's a
> > bug.
>
> Augh, yeah, I agree this is a pretty serious problem.
>
> > But ISTM it’d be better to copy the leader’s status flags to workers
> > in ParallelWorkerMain(). I've attached a patch for HEAD.
>
> Hmm, this affects not only PROC_IN_VACUUM and PROC_IN_SAFE_CIC (the bug
> you're fixing), but also:
>
> * PROC_IS_AUTOVACUUM. That seems reasonable to me -- should a parallel
> worker for autovacuum be considered autovacuum too? AFAICS it's only
> used by the deadlock detector, so it should be okay. However, in the
> normal path, that flag is set much earlier.
>
> * PROC_VACUUM_FOR_WRAPAROUND. Should be innocuous I think, since the
> "parent" process already has this flag and thus shouldn't be cancelled.

Currently, we don't support parallel vacuum for autovacuum. So
parallel workers for vacuum don't have these two flags.

> * PROC_IN_LOGICAL_DECODING. Surely not set for parallel vacuum workers,
> so not a problem.

Agreed.

Regards,

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