Re: pgsql: Don't consider newly inserted tuples in nbtree VACUUM.

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Don't consider newly inserted tuples in nbtree VACUUM.
Date: 2021-03-11 16:13:01
Message-ID: 20210311161301.GA14222@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On 2021-Mar-10, Peter Geoghegan wrote:

> On Wed, Mar 10, 2021 at 10:57 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > I think that this commit has some issues that need more thoughts.
> >
> > The removal of vacuum_cleanup_index_scale_factor means that any
> > existing deployment of Postgres that includes at least one index using
> > this parameter would fail in the middle of the restore during
> > pg_upgrade, when restoring the binary dump.
>
> I don't believe that it's necessary. Partly because it seems rather
> unlikely that vacuum_cleanup_index_scale_factor was ever set like this
> in practice.

I disagree; that GUC was a feature in its own right, and it seems likely
that people have set it in the hopes that it'd help them, even if it
didn't actually achieve that.

The GUC was added in April 2018 (pg11) and it's been possible to set it
on all releases since 11.0. That's a long time.

> You could have made the same arguments against removing
> recheck_on_update in commit 1c53c4de.

recheck_on_update was born on 11.0 and killed in time for 11.1, so its
opportunity to become set was narrower.

--
Álvaro Herrera 39°49'30"S 73°17'W
"La victoria es para quien se atreve a estar solo"

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2021-03-11 16:27:19 Re: pgsql: Drop index behind pg_upgrade test issue.
Previous Message Laurenz Albe 2021-03-11 09:36:37 Re: pgsql: Drop index behind pg_upgrade test issue.