Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Subject: Re: pg_amcheck contrib application
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: <20210316060913.GA3323238@rfd.leadboat.com>
Date: Tue, 16 Mar 2021 08:45:28 -0700
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Robert Haas <robertmhaas@gmail.com>,
 Peter Geoghegan <pg@bowt.ie>,
 Thomas Munro <thomas.munro@gmail.com>,
 "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
 Stephen Frost <sfrost@snowman.net>,
 Michael Paquier <michael@paquier.xyz>,
 Amul Sul <sulamul@gmail.com>,
 Dilip Kumar <dilipbalaut@gmail.com>,
 Andres Freund <andres@anarazel.de>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BCE9084-9381-471F-90F2-FAD99B7FE3DB@enterprisedb.com>
References: <A80D68F6-E38F-482D-9522-E2FB6AAFE8A1@enterprisedb.com>
 <CA+TgmoY3_U=QuQWo4DArBSp+tg2MiCHLwDN_9U2H_iTxj3UcjA@mail.gmail.com>
 <9E76E46A-48B2-4869-BD0C-422204C1F767@enterprisedb.com>
 <F0A1FD70-A2F4-4528-8A03-8650CAEC0554@enterprisedb.com>
 <20210313184612.GA3195145@rfd.leadboat.com>
 <930621E5-5D10-456D-8CE4-CF629A6C4669@enterprisedb.com>
 <20210313191841.GB3195145@rfd.leadboat.com>
 <3012106.1615827854@sss.pgh.pa.us>
 <C2C142F3-F740-4197-B507-20B28B7395AC@enterprisedb.com>
 <3053552.1615834640@sss.pgh.pa.us>
 <20210316060913.GA3323238@rfd.leadboat.com>
To: Noah Misch <noah@leadboat.com>
Archived-At: 
 <https://www.postgresql.org/message-id/7BCE9084-9381-471F-90F2-FAD99B7FE3DB%40enterprisedb.com>
Precedence: bulk


> On Mar 15, 2021, at 11:09 PM, Noah Misch <noah@leadboat.com> wrote:
>=20
>> Not sure that I believe the theory that this is from bad luck of
>> concurrent autovacuum timing, though.
>=20
> With autovacuum_naptime=3D1s, on hornet, the failure reproduced twice =
in twelve
> runs.  With =
v6-0001-Turning-off-autovacuum-during-corruption-tests.patch
> applied, 196 runs all succeeded.
>=20
>> The fact that we're seeing
>> this on just those two animals suggests strongly to me that it's
>> architecture-correlated, instead.
>=20
> 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.

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company