Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?

On Mon, Apr 4, 2022 at 7:02 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Yeah, I was very excited about verify_heapam(). There is a lot more
> stuff that we could check, but a lot of those things would be much
> more expensive to check.

If anything I understated the value of verify_heapam() with this kind
of work before. Better to show just how valuable it is using an
example.

Let's introduce a fairly blatant bug to lazyvacuum.c. This change
makes VACUUM fail to account for the fact that skipping a skippable
range with an all-visible page makes it unsafe to advance
relfrozenxid:

--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -1371,8 +1371,6 @@ lazy_scan_skip(LVRelState *vacrel, Buffer
*vmbuffer, BlockNumber next_block,
else
{
*skipping_current_range = true;
- if (skipsallvis)
- vacrel->skippedallvis = true;
}

return next_unskippable_block;

If I run "make check-world", the tests all pass! But when I run pg_amcheck
against an affected "regression" database, it will complain about
relfrozenxid related corruption in several different tables.

> It does a good job, I think, checking all the
> things that a human being could potentially spot just by looking at an
> individual page. I love the idea of using it in regression testing in
> more places. It might find bugs in amcheck, which would be good, but I
> think it's even more likely to help us find bugs in other code.

I'd really like it if amcheck had HOT chain verification. That's the
other area where catching bugs passively with assertions and whatnot
is clearly not good enough.

--
Peter Geoghegan