Re: PG 14 release notes, first draft - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: PG 14 release notes, first draft
Date
Msg-id CAH2-WzmzXdxY0w-WCo+9Pw-FL9eWiUjFHXEHBMxjMrSopgNB9A@mail.gmail.com
Whole thread Raw
In response to Re: PG 14 release notes, first draft  (Bruce Momjian <bruce@momjian.us>)
Responses Re: PG 14 release notes, first draft
List pgsql-hackers
On Tue, May 18, 2021 at 8:09 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I suppose that's true -- maybe it should be listed separately, because
> > the GUC is removed in 14 only.
>
> OK, this is a mess then.  Would someone please give me the full text for
> this, including the commit hash(es)?  Is the PG 13.3 release note text
> accurate?

The 13.3 release notes say this:

"""
Disable the vacuum_cleanup_index_scale_factor parameter and storage
option (Peter Geoghegan)

The notion of tracking “stale” index statistics proved to interact
badly with the autovacuum_vacuum_insert_threshold parameter, resulting
in unnecessary full-index scans and consequent degradation of
autovacuum performance. The latter mechanism seems superior, so remove
the stale-statistics logic. The control parameter for that,
vacuum_cleanup_index_scale_factor, will be removed entirely in v14. In
v13, it remains present to avoid breaking existing configuration
files, but it no longer does anything.
"""

I think that this is slightly inaccurate, though that's probably of
little consequence. The autovacuum_vacuum_insert_threshold GUC was in
fact removed in v14, but the reloption was ultimately not removed from
HEAD/v14 for compatibility reasons. This is not apparent just from
commit 9f3665fb -- there was a clean-up commit (commit effdd3f3) that
added the reloption back following further discussion. So the
equivalent reloption remains in place though is disabled, just for
compatibility purposes -- on v13 and v14. The GUC is where v13 and v14
differ -- only v13 still has the GUC to avoid breaking user's
postgresql.conf files (though it's also delisted). Deprecating a
reloption is much harder than deprecating a GUC.

In my opinion this should be interpreted as already handled by the
backpatch to 13.3, and so not necessary to handle again now -- despite
the GUC thing. It's possible that no users set the GUC at all, because
it wasn't particularly well thought out. This entire situation is
probably unprecedented (we just don't deprecate reloptions very
often), so I defer to your judgement, Bruce.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Multiple pg_waldump --rmgr options
Next
From: Bruce Momjian
Date:
Subject: Re: PG 14 release notes, first draft