On Thu, Mar 18, 2021 at 12:12 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Mark Dilger <mark.dil...@enterprisedb.com> writes: > >> On Mar 16, 2021, at 12:52 PM, Robert Haas <robertmh...@gmail.com> wrote: > >> Since we now know that shutting autovacuum off makes the problem go > >> away, I don't see a reason to commit 0001. We should fix pg_amcheck > >> instead, if, as presently seems to be the case, that's where the > >> problem is. > > > If you get unlucky, autovacuum will process one of the tables that the test > > intentionally corrupted, with bad consequences, ultimately causing build > > farm intermittent test failures. > > Um, yeah, the test had better shut off autovacuum on any table that > it intentionally corrupts.
Right, good point. But... does that really apply to 005_opclass_damage.pl? I feel like with the kind of physical damage we're doing in 003_check.pl, it makes a lot of sense to stop vacuum from crashing headlong into that table. But, 005 is doing "logical" damage rather than "physical" damage, and I don't see why autovacuum should misbehave in that kind of case. In fact, the fact that autovacuum can handle such cases is one of the selling points for the whole design of vacuum, as opposed to, for example, retail index lookups. Pending resolution of that question, I've committed the change to disable autovacuum in 003, and also Mark's changes to have it also run pg_amcheck BEFORE corrupting anything, so the post-corruption tests fail - say by finding the wrong kind of corruption - we can see whether it was also failing before the corruption was even introduced. -- Robert Haas EDB: http://www.enterprisedb.com
