Re: AIX support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Srirama Kucherlapati <sriram(dot)rk(at)in(dot)ibm(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tristan Partin <tristan(at)partin(dot)io>, AIX PG user <postgres-ibm-aix(at)wwpdl(dot)vnet(dot)ibm(dot)com>
Subject: Re: AIX support
Date: 2026-01-27 21:42:35
Message-ID: 581905.1769550155@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

... btw, I was annoyed to notice that AIX still does this in
64-bit builds:

checking size of void *... 8
checking size of size_t... 8
checking size of long... 8
checking size of long long... 8
checking size of intmax_t... 8
checking alignment of short... 2
checking alignment of int... 4
checking alignment of long... 8
checking alignment of int64_t... 8
checking alignment of double... 4

Normally we reject alignof(double) < alignof(int64), for the reasons
explained in configure.ac:

# We require 'double' to have the strictest alignment among the basic types,
# because otherwise the C ABI might impose 8-byte alignment on some of the
# other C types that correspond to TYPALIGN_DOUBLE SQL types. That could
# cause a mismatch between the tuple layout and the C struct layout of a
# catalog tuple. We used to carefully order catalog columns such that any
# fixed-width, attalign=4 columns were at offsets divisible by 8 regardless
# of MAXIMUM_ALIGNOF to avoid that, but we no longer support any platforms
# where TYPALIGN_DOUBLE != MAXIMUM_ALIGNOF.

I see that your patch summarily overrides that restriction (without
bothering to touch this comment), but I fear that the chances of
that being acceptable as-is are zero. We're not going to go back to
having to count bytes every time we change a system catalog rowtype
that involves an 'int8' or 'float8' column.

I think the only way we could deal with this in a maintainable
fashion would be to remove the assumption that int64 and double
have the same alignment requirement. That is tech debt that
we really should have cleaned up years ago anyway. The main
thing that's discouraged people from pursuing it is the fear
of adding overhead to tuple assembly/disassembly loops. But
I think maybe we could avoid adding such overhead by mapping
two different type alignment symbols at the source-code level
into appropriate values at runtime. Or a bunch of conditional
compilation, or whatever. Any modern machine is going to have
to be able to deal with both 4-byte and 8-byte alignment
requirements, it's just a question of which datatypes have
which requirement.

While I don't foresee that being an enormous patch, it's not trivial
either. I'd encourage you to write and submit it as a separate patch
rather than something directly tied to the AIX-restoration patch.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-01-27 21:50:15 Re: AIX support
Previous Message Robert Haas 2026-01-27 21:11:26 Re: pg_waldump: support decoding of WAL inside tarfile