Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Mar 16, 2021 at 1:48 PM Tom Lane <t...@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
