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

On 2021-Mar-11, Peter Geoghegan wrote:

> On Thu, Mar 11, 2021 at 8:13 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > 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.
>
> Michael was talking about the reloption, not the GUC. Surely the GUC
> is not the problem here - there is plenty of precedent for removing
> GUCs that were around for many releases, without considering
> compatibility.

Sorry, yes, I meant the reloption. I agree we don't care about the GUC.

> > > 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.
>
> New reloptions are added infrequently. And they're practically never
> removed. So recheck_on_update seems to be the closest thing to a
> precedent.

Given the short life of recheck_on_update I don't think we should
consider it a precedent.

> I now accept that the dump/reload hazards when upgrading to 14 are not
> acceptable. ISTM that adding back the reloption on master/Postgres 14
> (without doing anything with it) is the only way to fix everything.

Yeah, I agree. It would be slightly better to ignore it on input (ie.
make ALTER TABLE SET a no-op for that case), but I don't think we have
code to do that.

> Any thoughts on that plan? I can do that in the next few hours if
> there are no objections.

Sounds good to me.

--
Álvaro Herrera 39°49'30"S 73°17'W