> On Nov 6, 2021, at 3:09 PM, Peter Geoghegan <p...@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 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
