Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode

On Tue, Apr 4, 2023 at 8:14 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> 14. Not related to this patch, but why do we have half the vacuum
> related GUCs in vacuum.c and the other half in globals.c? I see
> vacuum_freeze_table_age is defined in vacuum.c but is also needed in
> autovacuum.c, so that rules out the globals.c ones being for vacuum.c
> and autovacuum.c. It seems a bit messy. I'm not really sure where
> VacuumBufferUsageLimit should go now.

vacuum_freeze_table_age is an abomination, even compared to the rest
of these GUCs. It was added around the time the visibility map first
went in, and so is quite a bit more recent than
autovacuum_freeze_max_age.

Before the introduction of the visibility map, we only had
autovacuum_freeze_max_age, and it was used to schedule antiwraparound
autovacuums -- there was no such thing as aggressive VACUUMs (just
antiwraparound autovacuums), and no need for autovacuum_freeze_max_age
at all. So autovacuum_freeze_max_age was just for autovacuum.c code.
There was only one type of VACUUM, and they always advanced
relfrozenxid to the same degree.

With the introduction of the visibility map, we needed to have
autovacuum_freeze_max_age in vacuum.c for the first time, to deal with
interpreting the then-new vacuum_freeze_table_age GUC correctly. We
silently truncate the vacuum_freeze_table_age setting so that it never
exceeds 95% of autovacuum_freeze_max_age (the
105%-of-autovacuum_freeze_max_age vacuum_failsafe_age thing that
you're discussing is symmetric). So after 2009
autovacuum_freeze_max_age actually plays an important role in VACUUM,
the command, and not just autovacuum.

This is related to the problem of the autovacuum_freeze_max_age
reloption being completely broken [1]. If autovacuum_freeze_max_age
was still purely just an autovacuum.c scheduling thing, then there
would be no problem with having a separate reloption of the same name.
There are big problems precisely because vacuum.c doesn't do anything
with the autovacuum_freeze_max_age reloption. Though it does okay with
the autovacuum_freeze_table_age reloption, which gets passed in. (Yes,
it's called autovacuum_freeze_table_age in reloption form -- not
vacuum_freeze_table_age, like the GUC).

Note that the decision to ignore the reloption version of
autovacuum_freeze_max_age in the failsafe's
105%-of-autovacuum_freeze_max_age thing was a deliberate one. The
autovacuum_freeze_max_age GUC is authoritative in the sense that it
cannot be overridden locally, except in the direction of making
aggressive VACUUMs happen more frequently for a given table (so they
can't be less frequent via reloption configuration). I suppose you'd
have to untangle that mess if you wanted to fix the
autovacuum_freeze_max_age reloption issue I go into in [1].

[1] https://postgr.es/m/CAH2-Wz=DJAokY_GhKJchgpa8k9t_H_OVOvfPEn97jGNr9W=deg@mail.gmail.com
--
Peter Geoghegan