Re: PG 14 release notes, first draft

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: PG 14 release notes, first draft
Дата
Msg-id CAH2-WzmzXdxY0w-WCo+9Pw-FL9eWiUjFHXEHBMxjMrSopgNB9A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PG 14 release notes, first draft  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: PG 14 release notes, first draft  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Multiple pg_waldump --rmgr options
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: PG 14 release notes, first draft