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 CAD21AoBJwiAbTkjCFeFmHzH6F_ySU8pO2k_2Mkzb6TVd0tLmoA@mail.gmail.com
Whole thread Raw
In response to Re: Parallel vacuum workers prevent the oldest xmin from advancing  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Parallel vacuum workers prevent the oldest xmin from advancing
List pgsql-hackers
On Mon, Oct 11, 2021 at 9:51 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Oct 11, 2021 at 09:23:32AM +0900, Masahiko Sawada wrote:
> > On Sat, Oct 9, 2021 at 12:13 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >> * 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.
>
> That's something that should IMO be marked in the code as a comment as
> something to worry about once/if someone begins playing with parallel
> autovacuum.  If the change involving autovacuum is simple, I see no
> reason to not add this part now, though.

Agreed. I added the comment. Also, I added an assertion to ensure that
a parallel worker for vacuum has PROC_IN_VACUUM flag (and doesn't have
other flags). But we cannot do that for parallel workers for building
btree index as they don’t know whether or not the CONCURRENTLY option
is specified.

Regards,

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

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Added schema level support for publication.