On Sat, Jul 2, 2022 at 2:34 PM Andres Freund <and...@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=7u07tja59wt...@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
