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

From Masahiko Sawada
Subject Re: Parallel vacuum workers prevent the oldest xmin from advancing
Date
Msg-id CAD21AoDMCQBY_0EobM8WbH5ZzVskz6HjAQpxQ4dTWtH+aiHjNw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel vacuum workers prevent the oldest xmin from advancing  (Greg Nancarrow <gregn4422@gmail.com>)
List pgsql-hackers
On Mon, Oct 11, 2021 at 3:01 PM Greg Nancarrow <gregn4422@gmail.com> wrote:
>
> On Wed, Oct 6, 2021 at 6:11 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > To fix it, I thought that we change the create index code and the
> > vacuum code so that the individual parallel worker sets its status
> > flags according to the leader’s one. But ISTM it’d be better to copy
> > the leader’s status flags to workers in ParallelWorkerMain(). I've
> > attached a patch for HEAD.
> >
>
> +1 The fix looks reasonable to me too.
> Is it possible for the patch to add test cases for the two identified
> problem scenarios? (PROC_IN_VACUUM, PROC_IN_SAFE_IC)

Not sure we can add stable tests for this. There is no way in the test
infra to control parallel workers to suspend and resume etc. and the
oldest xmin can vary depending on the situation. Probably we can add
an assertion to ensure a parallel worker for vacuum or create index
has PROC_IN_VACUUM or PROC_IN_SAFE_IC, respectively.

Regards,

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



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations