Re: PG 14 release notes, first draft

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 14 release notes, first draft
Date: 2021-05-18 15:34:55
Message-ID: CAH2-WzmzXdxY0w-WCo+9Pw-FL9eWiUjFHXEHBMxjMrSopgNB9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 18, 2021 at 8:09 AM Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-05-18 15:48:10 Re: PG 14 release notes, first draft
Previous Message Julien Rouhaud 2021-05-18 15:23:02 Re: Multiple pg_waldump --rmgr options