Re: AIX support - alignment issues
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-07-06T15:55:57Z
Lists: 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
Commits
-
Doc: Acknowledge historically supported CPUs and OSes.
- 14168d3c62fa 16.0 landed
-
Further tidy-up for old CPU architectures.
- 718aa43a4ee6 16.0 landed
-
Tidy up claimed supported CPUs and OSes.
- 92d70b77ebb4 16.0 landed
-
Remove HP/Intel Itanium support.
- 0ad5b48e5894 16.0 landed
-
Remove HP-UX port.
- 9db300ce6e38 16.0 landed
-
Reorder subskiplsn in pg_subscription to avoid alignment issues.
- 79b716cfb7a1 15.0 cited
-
Tighten TAP tests' tracking of postmaster state some more.
- 4fdbf9af5184 15.0 cited
-
Reorder pg_sequence columns to avoid alignment issue
- f3b421da5f4a 10.0 cited