> On Mar 15, 2021, at 11:09 PM, Noah Misch <n...@leadboat.com> wrote:
>
>> Not sure that I believe the theory that this is from bad luck of
>> concurrent autovacuum timing, though.
>
> With autovacuum_naptime=1s, on hornet, the failure reproduced twice in twelve
> runs. With v6-0001-Turning-off-autovacuum-during-corruption-tests.patch
> applied, 196 runs all succeeded.
>
>> The fact that we're seeing
>> this on just those two animals suggests strongly to me that it's
>> architecture-correlated, instead.
>
> That is possible.
I think autovacuum simply triggers the bug, and is not the cause of the bug.
If I turn autovacuum off and instead do an ANALYZE in each test database rather
than performing the corruptions, I get reports about problems in pg_statistic.
This is on my mac laptop. This rules out the theory that autovacuum is
propogating corruptions into pg_statistic, and also the theory that it is
architecture dependent.
I'll investigate further.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
