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

On Wed, 5 Apr 2023 at 16:37, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Tue, Apr 4, 2023 at 8:14 PM David Rowley <dgrowleyml@gmail.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

I read this twice yesterday and again this morning. It looks like
you're taking an opportunity to complain/vent about
vacuum_freeze_table_age and didn't really answer my query about why
all the vacuum GUCs aren't defined in the one file.  I'd just picked
vacuum_freeze_table_age as a random one from vacuum.c to raise the
point about the inconsistency about the GUC locations.

 I don't think this is the place to raise concerns with existing GUCs,
but if you did have a point about the GUCs locations, then you might
need to phase it differently as I didn't catch it.

David