Re: New IndexAM API controlling index vacuum strategies - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: New IndexAM API controlling index vacuum strategies
Date
Msg-id CAH2-Wz=eTZT7bBtr47OXoEbf7DBabBDRQ2ZFxx=nkE1QSyUA1Q@mail.gmail.com
Whole thread Raw
In response to Re: New IndexAM API controlling index vacuum strategies  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New IndexAM API controlling index vacuum strategies  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Apr 5, 2021 at 4:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > Do you think that it's okay that we rely on the propagation of global
> > state to parallel workers on Postgres 13? Don't we need something like
> > my fixup commit 49f49def on Postgres 13 as well? At least for the
> > EXEC_BACKEND case, I think.
>
> Uh ... *what* propagation of global state to parallel workers?  Workers
> fork off from the postmaster, not from their leader process.
>
> (I note that morepork is still failing.  The other ones didn't report
> in yet.)

Evidently my fixup commit 49f49def was written in way too much of a
panic. I'm going to push a new fix shortly. This will make workers do
their own GetAccessStrategy(BAS_VACUUM), just to get the buildfarm
green.

REL_13_STABLE will need to be considered separately. I still haven't
figured out how this ever appeared to work for this long. The
vac_strategy/bstrategy state simply wasn't propagated at all.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: postgres_fdw: IMPORT FOREIGN SCHEMA ... LIMIT TO (partition)
Next
From: Andres Freund
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies