Re: pg_amcheck contrib application

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