On 26/02/2024 06:18, Michael Paquier wrote:
> On Mon, Feb 26, 2024 at 09:42:03AM +0530, Robert Haas wrote:
>> On Mon, Feb 26, 2024 at 1:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> So, we now need to strip the remnants of AIX support from the code and
>>> docs? I don't see that much of it, but it's misleading to leave it
>>> there.
>>>
>>> (BTW, I still want to nuke the remaining snippets of HPPA support.
>>> I don't think it does anybody any good to make it look like that's
>>> still expected to work.)
>>
>> +1 for removing things that don't work (or that we think probably don't work).
>
> Seeing this stuff eat developer time because of the debugging of weird
> issues while having a very limited impact for end-users is sad, so +1
> for a cleanup of any remnants if this disappears.
Here's a patch to fully remove AIX support.
One small issue that warrants some discussion (in sanity_check.sql):
> --- When ALIGNOF_DOUBLE==4 (e.g. AIX), the C ABI may impose 8-byte alignment on
> +-- When MAXIMUM_ALIGNOF==8 but ALIGNOF_DOUBLE==4, the C ABI may impose 8-byte alignment
> -- some of the C types that correspond to TYPALIGN_DOUBLE SQL types. To ensure
> -- catalog C struct layout matches catalog tuple layout, arrange for the tuple
> -- offset of each fixed-width, attalign='d' catalog column to be divisible by 8
> -- unconditionally. Keep such columns before the first NameData column of the
> -- catalog, since packagers can override NAMEDATALEN to an odd number.
> +-- (XXX: I'm not sure if any of the supported platforms have MAXIMUM_ALIGNOF==8 and
> +-- ALIGNOF_DOUBLE==4. Perhaps we should just require that
> +-- ALIGNOF_DOUBLE==MAXIMUM_ALIGNOF)
What do y'all think of adding a check for
ALIGNOF_DOUBLE==MAXIMUM_ALIGNOF to configure.ac and meson.build? It's
not a requirement today, but I believe AIX was the only platform where
that was not true. With AIX gone, that combination won't be tested, and
we will probably break it sooner or later.
--
Heikki Linnakangas
Neon (https://neon.tech)