On Tue, Feb 25, 2025 at 11:36 AM Greg Sabino Mullane <htamf...@gmail.com> wrote: > > On Tue, Feb 25, 2025 at 11:03 AM Melanie Plageman <melanieplage...@gmail.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
