Re: AIX support - alignment issues - Mailing list pgsql-hackers

From Robert Haas
Subject Re: AIX support - alignment issues
Date
Msg-id CA+TgmoaVeuFJBY8G9gKHSfEgM+cDx0qNAWh84EE7VX2N_asoAQ@mail.gmail.com
Whole thread Raw
In response to AIX support - alignment issues  (Andres Freund <andres@anarazel.de>)
Responses Re: AIX support - alignment issues
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Issue with pg_stat_subscription_stats
Next
From: Robert Haas
Date:
Subject: Re: making relfilenodes 56 bits