From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Mark Dilger <mark.dilger@enterprisedb.com>,
 Noah Misch <noah@leadboat.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>
Subject: Re: pg_amcheck contrib application
In-reply-to: 
 <CA+TgmoYFwii3cgfc-yNzEgFce=zWP08Nt56pAyffqpXjgg1UxA@mail.gmail.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>
 <7BCE9084-9381-471F-90F2-FAD99B7FE3DB@enterprisedb.com>
 <3254547.1615910855@sss.pgh.pa.us>
 <7CFAF7EF-4EA7-4CB6-B2C7-EC7F4512AE50@enterprisedb.com>
 <16B79A18-48F3-404D-8DC5-53528E85A7AC@enterprisedb.com>
 <CA+TgmoYFwii3cgfc-yNzEgFce=zWP08Nt56pAyffqpXjgg1UxA@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 16 Mar 2021 12:56:40 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3360173.1615916917.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Mar 2021 13:48:37 -0400
Message-ID: <3360174.1615916917@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3360174.1615916917%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 16, 2021 at 12:51 PM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
>> It shows them all has having attalign =3D 'd', but for some array types=
 the alignment will be 'i', not 'd'.  So it's lying a bit about the conten=
ts.  But I'm now confused why this caused problems on the two hosts where =
integer and double have the same alignment?  It seems like that would be t=
he one place where the bug would not happen, not the one place where it do=
es.

> Wait, so the value in the attalign column isn't the alignment we're
> actually using? I can understand how we might generate tuples like
> that, if we pass the actual type to construct_array(), but shouldn't
> we then get garbage when we deform the tuple?

No.  What should be happening there is that some arrays in the column
get larger alignment than they actually need, but that shouldn't cause
a problem (and has not done so, AFAIK, in the decades that it's been
like this).  As you say, deforming the tuple is going to rely on the
table's tupdesc for alignment; it can't know what is in the data.

I'm not entirely sure what's going on, but I think coming at this
with the mindset that "amcheck has detected some corruption" is
just going to lead you astray.  Almost certainly, it's "amcheck
is incorrectly claiming corruption".  That might be from mis-decoding
a TOAST-referencing datum.  (Too bad the message doesn't report the
TOAST OID it probed for, so we can see if that's sane or not.)

			regards, tom lane