Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?
Date
Msg-id CAH2-Wzmfwj_61U8VoSxY-NTiPvAJD7D-aTCO43-+q273oPdq8g@mail.gmail.com
Whole thread Raw
In response to Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?  (Andres Freund <andres@anarazel.de>)
Responses Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?  (Robert Haas <robertmhaas@gmail.com>)
Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Sun, Apr 3, 2022 at 11:53 AM Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
Next
From: Noah Misch
Date:
Subject: Re: Skipping logical replication transactions on subscriber side