pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Noah Misch <noah@leadboat.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 14:57:20 -0400
Message-ID: <3053552.1615834640@sss.pgh.pa.us> (raw)
In-Reply-To: <C2C142F3-F740-4197-B507-20B28B7395AC@enterprisedb.com>
References: <CAH2-WzmZJ3MWjaSEaysmkP8A7WL_TiCwOS8eT88yc-bwHgLOKg@mail.gmail.com>
	<CAH2-WznpwULZ3uJ1_6WXvNMXYbOy8k8tYs3r=qSdGmZeRd6tDw@mail.gmail.com>
	<CA+TgmoZUJ4j31CbnUz-DpBBq_DVoaYcuG5XB7hP71+uQ=js_KQ@mail.gmail.com>
	<CA+TgmoZ1DP0pkLyuG9y7Jtn2v7N-+dnVxbvBAT__u4-d=UYmbw@mail.gmail.com>
	<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>

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.

> 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.  The fact that we're seeing
this on just those two animals suggests strongly to me that it's
architecture-correlated, instead.

			regards, tom lane





view thread (161+ messages)  latest in thread

Message-ID: <3053552.1615834640@sss.pgh.pa.us>
Permalink:  ../3053552.1615834640@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3053552.1615834640@sss.pgh.pa.us

 · 

reply
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: tgl@sss.pgh.pa.us, mark.dilger@enterprisedb.com, noah@leadboat.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: <3053552.1615834640@sss.pgh.pa.us>

* 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