> On Nov 6, 2021, at 3:09 PM, Peter Geoghegan <pg@bowt.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
alreadysubmitted 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
inspiredby your comments about the "freeze the dead" bug. We need to be able to build versions of the database with
knownbugs enabled, both real-world bugs from the past and contrived bugs we write only for this purpose, so as to
createnon-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
branchwhile periodically merging in everything else from HEAD? That seems a tad tiresome, but maybe it wouldn't be too
badif the intentional bugs were limited to just a few backend files, and as much as possible in code at the end of the
fileor 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
