On Tue, Jul 5, 2022 at 1:32 AM Andres Freund <and...@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