On Tue, Jul 5, 2022 at 1:32 AM Andres Freund <andres@anarazel.de> wrote:
> I just thought an easier way - why don't we introduce a 'catalog_double'
> that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we
> can get rid of the manually enforced alignedness and we don't need to contort
> catalog order.
I investigated this a little bit today. It seems that
att_align_nominal() thinks that typalign=='d' means ALIGNOF_DOUBLE,
which on AIX is 4. So I think what we would need to do first is
redefine typalign=='d' to mean alignment to MAXIMUM_ALIGNOF. If we
don't do that, then there's no automatic way to get uint64 fields to
be placed on 8-byte boundaries, which it requires. Such a change would
have no effect on many systems, but if as on AIX double requires less
alignment than either "long" or "long long int", it will break on-disk
compatibility and in particular pg_upgrade compatibility.
If we did that, then we could pursue your proposal above. Rather than
creating an altogether new typedef, we could just apply
pg_attribute_aligned(MAXIMUM_ALIGNOF) to the existing typedef for
float8, which is documented as being the name that should be used in
the catalogs, and is. Since pg_attribute_aligned() is not supported on
all platforms, we elsewhere apply it conditionally, so we would
presumably do the same thing here. That would mean that it might fail
to apply on some platform somewhere, but we could compensate for that
by adding a static assertion checking that if we do struct
float8_alignmment_test { char pad; float8 x; } then
alignof(float8_alignment_test, x) == MAXIMUM_ALIGNOF. That way, if
pg_attribute_aligned() isn't supported but the platform doesn't have
this issue in the first place, all is well. If pg_attribute_aligned()
isn't supported and the platform does have this issue, compilation
will fail.
In theory, we could have the same issue with int64 on some other
platform. On this hypothetical system, ALIGNOF_LONG_LONG_INT <
ALIGNOF_DOUBLE. The compile would then align int64 catalog columns on,
say, 4-byte boundaries, but our tuple deforming code would think that
they were aligned to 8 byte boundaries. We could fix that by forcing
the int64 type to have maximum alignment as well or introducing a new
typedef that does. However, such a fix could probably be postponed
until such time as a system of this kind turns up. It might never
happen.
--
Robert Haas
EDB: http://www.enterprisedb.com
