Re: Trigger more frequent autovacuums of heavy insert tables

On Tue, Feb 25, 2025 at 11:36 AM Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote:
>
> On Tue, Feb 25, 2025 at 11:03 AM Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
>>
>> Because users can now manually update these values in pg_class, there wouldn't be a way to detect the difference
>> between a bogus relallfrozen value due to VM corruption or a bogus value due to manual statistics intervention.
>
> Er..you had me until this. If manual monkeying of the system catalogs leads to a "bogus" error that resembles a real one, then sow the wind, and reap the whirlwind. I don't think that should be a consideration here.

Oh, the WARNING would only show up in a case of actual VM corruption.
The WARNING proposed is after calling visibilitymap_count() before
updating pg_class, if the value we get from the VM for relallfrozen
exceeds relallvisible. If you manually change pg_class
relallfrozen/relallvisible to bogus values, you wouldn't get a
warning. I meant there wouldn't be a way to detect the difference when
viewing pg_class between bogus values because of a corrupt VM and
bogus values because of manual updates to pg_class.

- Melanie