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+TgmoaO8Qsn6i61f=trihm3qjcim-scNW9uq2jrUAUhydRXOQ@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>
 <3360174.1615916917@sss.pgh.pa.us>
 <CA+TgmoaO8Qsn6i61f=trihm3qjcim-scNW9uq2jrUAUhydRXOQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 16 Mar 2021 14:24:23 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3387833.1615920313.1@sss.pgh.pa.us>
Date: Tue, 16 Mar 2021 14:45:13 -0400
Message-ID: <3387834.1615920313@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3387834.1615920313%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 16, 2021 at 1:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> OK, I don't understand this. attalign is 'd', which is already the
> maximum possible, and even if it weren't, individual rows can't decide
> to use a larger OR smaller alignment than expected without breaking
> stuff.

> In what context is it OK to just add extra alignment padding?

It's *not* extra, according to pg_statistic's tuple descriptor.
Both forming and deforming of pg_statistic tuples should honor
that and locate stavaluesX values on d-aligned boundaries.

It could be that a particular entry is of an array type that
only requires i-alignment.  But that doesn't break anything,
it just means we inserted more padding than an omniscient
implementation would do.

(I suppose in some parallel universe there could be a machine
where i-alignment is stricter than d-alignment, and then we'd
have trouble.)

			regards, tom lane