On Tue, Apr 4, 2023 at 8:14 PM David Rowley <dgrowle...@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=d...@mail.gmail.com -- Peter Geoghegan
