On Sat, Oct 9, 2021 at 12:13 AM Alvaro Herrera <alvhe...@alvh.no-ip.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/
