From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrey M. Borodin <x4mmm@yandex-team.ru>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Amul Sul <sulamul@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: pg_amcheck contrib application
Date: Mon, 15 Mar 2021 23:09:13 -0700
Message-ID: <20210316060913.GA3323238@rfd.leadboat.com> (raw)
In-Reply-To: <3053552.1615834640@sss.pgh.pa.us>
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>
On Mon, Mar 15, 2021 at 02:57:20PM -0400, Tom Lane wrote:
> Mark Dilger <mark.dilger@enterprisedb.com> writes:
> > On Mar 15, 2021, at 10:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> These animals have somewhat weird alignment properties: MAXALIGN is 8
> >> but ALIGNOF_DOUBLE is only 4. I speculate that that is affecting their
> >> choices about whether an out-of-line TOAST value is needed, breaking
> >> this test case.
That machine also has awful performance for filesystem metadata operations,
like open(O_CREAT). Its CPU and read()/write() performance are normal.
> > The logic in verify_heapam only looks for a value in the toast table if
> > the tuple it gets from the main table (in this case, from pg_statistic)
> > has an attribute that claims to be toasted. The error message we're
> > seeing that you quoted above simply means that no entry exists in the
> > toast table.
>
> Yeah, that could be phrased better. Do we have a strong enough lock on
> the table under examination to be sure that autovacuum couldn't remove
> a dead toast entry before we reach it? But this would only be an
> issue if we are trying to check validity of toasted fields within
> known-dead tuples, which I would argue we shouldn't, since lock or
> no lock there's no guarantee the toast entry is still there.
>
> 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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, tgl@sss.pgh.pa.us, mark.dilger@enterprisedb.com, robertmhaas@gmail.com, pg@bowt.ie, thomas.munro@gmail.com, x4mmm@yandex-team.ru, sfrost@snowman.net, michael@paquier.xyz, sulamul@gmail.com, dilipbalaut@gmail.com, andres@anarazel.de
Subject: Re: pg_amcheck contrib application
In-Reply-To: <20210316060913.GA3323238@rfd.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox