On Sat, Jul 2, 2022 at 2:34 PM Andres Freund <andres@anarazel.de> wrote:
> I strikes me as a remarkably bad idea to manually try to maintain the correct
> alignment. Even with the tests added it's still quite manual and requires
> contorted struct layouts (see e.g. [1]).
>
> I think we should either teach our system the correct alignment rules or we
> should drop AIX support.
I raised this same issue at
http://postgr.es/m/CA+TgmoaK377MXCWJqEXM3VvKDDC-frNUMKb=7u07TJa59wTAeQ@mail.gmail.com
and discussion ensued from there. I agree that manually maintaining
alignment, even with a regression test to help, is a really bad plan.
The rule about columns of type "name" can be relaxed easily enough,
just by insisting that NAMEDATALEN must be a multiple of 8. As Tom
also said on this thread, adding such a constraint seems to have no
real downside. But the problem has a second aspect not related to
NameData, which is that int64 and double have different alignment
requirements on that platform. To get out from under that part of it,
it seems we either need to de-support AIX and any other platforms that
have such a discrepancy, or else have separate typalign values for
int64-align vs. double-align.
From a theoretical point of view, I think what we're doing now is
pretty unprincipled. I've always found it a bit surprising that we get
away with just assuming that a bunch of various different primitive
data types are all going to have the same alignment requirement. The
purist in me feels that it would be better to have separate typalign
values for things that aren't guaranteed to behave the same. However,
there's a practical difficulty with that approach: if the only
operating system where this issue occurs in practice is AIX, I feel
it's going to be pretty hard for us to keep the code that caters to
this unusual situation working properly. And I'd rather have no code
for it at all than have code which doesn't really work.
--
Robert Haas
EDB: http://www.enterprisedb.com
