Re: Parallel vacuum workers prevent the oldest xmin from advancing - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Parallel vacuum workers prevent the oldest xmin from advancing
Date
Msg-id 202110081513.sbh4wgitnb5v@alvherre.pgsql
Whole thread Raw
In response to Parallel vacuum workers prevent the oldest xmin from advancing  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Parallel vacuum workers prevent the oldest xmin from advancing  (Peter Geoghegan <pg@bowt.ie>)
Re: Parallel vacuum workers prevent the oldest xmin from advancing  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
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.

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

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"Doing what he did amounts to sticking his fingers under the hood of the
implementation; if he gets his fingers burnt, it's his problem."  (Tom Lane)



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: dfmgr additional ABI version fields
Next
From: Alvaro Herrera
Date:
Subject: Re: RFC: compression dictionaries for JSONB