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

On Sun, Apr 3, 2022 at 11:53 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> We've had bugs in pg_upgrade where post-upgrade xid horizons weren't correctly
> set. We've had bugs were indexes were corrupted during replay.
>
> The latter can be caught by wal_consistency_checking - but that's pretty
> expensive.
>
> It seems $subject would have a chance of catching some of these bugs, as well
> as exposing amcheck to a database with a bit more varied content?

I thought that Andrew Dunstan (CC'd) had a BF animal that did this
setup. But I'm not sure if that ever ended up happening.

I meant to tell the authors of verify_heapam() (also CC'd) that it
really helped with my recent VACUUM project. While the assertions that
I wrote in vacuumlazy.c might catch certain bugs like this,
verify_heapam() is much more effective in practice.

Let's say that an all-visible page (or all-frozen page) has XIDs from
before relfrozenxid. Why should the next VACUUM (or any VACUUM) be
able to observe the problem? A testing strategy that doesn't rely on
these kinds of accidental details to catch bugs is far better than one
that does.

Definitely all in favor of using verify_heapam() to its full
potential. So I'm +1 on your proposal.

--
Peter Geoghegan