Re: amcheck's verify_heapam(), and HOT chain verification

> On Nov 6, 2021, at 3:09 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> I am quite willing to help out with all this, if you're interested.

Yes, I am quite interested, though I will have to alternate between this work and the various patch sets that I've already submitted for this development cycle.

I think we need a corruption generating framework that can be deployed on the buildfarm. What I have in mind is inspired by your comments about the "freeze the dead" bug. We need to be able to build versions of the database with known bugs enabled, both real-world bugs from the past and contrived bugs we write only for this purpose, so as to create non-trivial corruption on the build farm. I think it would be sufficient if such builds were run less frequently, perhaps triggered by commits to a corruption testing branch? We could keep the old bugs alive on that branch while periodically merging in everything else from HEAD? That seems a tad tiresome, but maybe it wouldn't be too bad if the intentional bugs were limited to just a few backend files, and as much as possible in code at the end of the file or in separate files to reduce merge conflicts?

I'm cc'ing Andrew to get his thoughts about the buildfarm integration....

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company