Horton

Thread

Commits

  1. Cope with AIX's alignment woes by using _Pragma("pack").

  2. Make some minor cleanups in typalign-related code.

  3. Refactor att_align_nominal() to improve performance.

  1. Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-29T01:20:24Z

    Over in the long-running thread about resurrecting AIX support,
one salient concern is that AIX has alignof(int64) = 8 but
alignof(double) = 4.  This breaks all our code that supposes
that ALIGNOF_DOUBLE is the platform's maximum alignment spec.
We had coped with this via various unspeakable klugery back
when AIX was considered supported, but nobody wants to put
back those restrictions if we re-support AIX.  (See my gripe
at [1], but I believe Heikki and Andres complained of this
in more detail long ago.)

Here is a modest proposal for fixing that in a clean way.
Let's break TYPALIGN_DOUBLE into three values, TYPALIGN_DOUBLE
for float8 only, TYPALIGN_INT64 for 64-bit integral types
including pointers, and TYPALIGN_MAX to represent MAXALIGN
alignment regardless of which of the first two determine it.
We need TYPALIGN_MAX because that's the value composite
types should use, so that their alignment doesn't change
if somebody adds or deletes a column of a relevant type.
Given that design, the patch is pretty straightforward,
and smaller than I feared it might be.  (Though I might
have missed a spot or two.)

I think this is good cleanup and deserves consideration
whether we accept the AIX patch soon or not.

A loose end that deserves mention is that I noticed we
are very inconsistent about the length/alignment
attributed to polymorphic types:

select typname, typlen, typalign from pg_type where typname like 'any%';
         typname         | typlen | typalign 
-------------------------+--------+----------
 any                     |      4 | i
 anyarray                |     -1 | m
 anycompatible           |      4 | i
 anycompatiblearray      |     -1 | m
 anycompatiblemultirange |     -1 | m
 anycompatiblenonarray   |      4 | i
 anycompatiblerange      |     -1 | m
 anyelement              |      4 | i
 anyenum                 |      4 | i
 anymultirange           |     -1 | m
 anynonarray             |      4 | i
 anyrange                |     -1 | m
(12 rows)

(Previous to this patch, the 'm' entries were 'd'.)

In one sense this doesn't really matter, since no actual
value should have any of these types attributed to it;
but it annoys me that they're not all alike.  I'm tempted to
make them all 4/'i' which seems to be the older convention.

A more aggressive answer would be to change these to some
actually-illegal values, in hopes of catching anyplace where
we did try to rely on the values.  But that seems like
material for a different patch.

			regards, tom lane

[1] https://www.postgresql.org/message-id/581905.1769550155%40sss.pgh.pa.us

  2. Re: Decoupling our alignment assumptions about int64 and double

    Andres Freund <andres@anarazel.de> — 2026-01-29T16:13:16Z

    Hi,

Thanks for the patch.  Looks like a decent improvement.


On 2026-01-28 20:20:24 -0500, Tom Lane wrote:
> One of the concerns that prevented this from being done long
> ago was not wanting to add overhead to tuple forming/deforming.
> However that concern seems gone now, because we map TYPALIGN_xxx
> values to numeric alignments in populate_compact_attribute()
> which is not so performance-critical.  It might be worth
> worrying about the increased cost of att_align_nominal(),
> but that macro is not that heavily used IMO.

Yea, it shouldn't matter too much these days.  We might want to verify that
the array code isn't overly affected, e.g. array_iter_next() was deemed perf
critical enough by someone to make it an inline function. I don't know if the
compiler is somehow smart enough to move the conditionals outside of a loop
over array_iter_next().

Perhaps we should make att_align_nominal() first determine the numerical
alignment value and then have it use TYPEALIGN()? I think that'd be more
likely to be pulled out of loops by the compile.


Perhaps it's time to reformat att_align_nominal() into an static inline? It's
pretty hard to read.


I don't love the 'l' for TYPALIGN_INT64, but I guess I don't really have a
better suggestion.


It wouldn't hurt to have a short SQL level test for creating a type with int8
& max alignments.

Greetings,

Andres Freund

  3. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-29T16:33:14Z

    Andres Freund <andres@anarazel.de> writes:
> Thanks for the patch.  Looks like a decent improvement.

Thanks for looking!

> On 2026-01-28 20:20:24 -0500, Tom Lane wrote:
>> ... It might be worth
>> worrying about the increased cost of att_align_nominal(),
>> but that macro is not that heavily used IMO.

> Perhaps we should make att_align_nominal() first determine the numerical
> alignment value and then have it use TYPEALIGN()? I think that'd be more
> likely to be pulled out of loops by the compile.

Yeah, I was thinking about actually breaking that into two source-code
steps, a function to map TYPALIGN_xxx to numeric alignment and then a
replacement for att_align_nominal that takes a numeric alignment.
If you think it's worth worrying about I'm happy to do that.

> Perhaps it's time to reformat att_align_nominal() into an static inline? It's
> pretty hard to read.

+1, I was not revisiting any of that for this draft, but if we're going
to refactor it then an inline function seems good.

> I don't love the 'l' for TYPALIGN_INT64, but I guess I don't really have a
> better suggestion.

Of course I was thinking 'l' for "long", but I agree it's not great
typographically.  One idea is 'L' not 'l', but that gives up
consistency for visual separation.  Any other ideas out there?

> It wouldn't hurt to have a short SQL level test for creating a type with int8
> & max alignments.

hmm ... yeah, I guess those code paths might not be covered already.

			regards, tom lane

  4. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-30T01:21:20Z

    Here's a v2 responding to your suggestions.  0001 refactors
att_align_nominal(), and then 0002 is nearly the same as the
prior patch except for rebasing over that change.  I added
a test case for alignment = max too (the other cases seem
covered already, somewhat indirectly via pg_upgrade testing).

I think this might be about ready to go, unless somebody has
a better idea than 'l' for the catalog representation of
TYPALIGN_INT64.

			regards, tom lane

  5. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-31T04:46:08Z

    I wrote:
> I think this might be about ready to go, unless somebody has
> a better idea than 'l' for the catalog representation of
> TYPALIGN_INT64.

I realized that there is more to consider here than we'd thought.
In particular, while we've mainly worried about what happens with
system catalog row layout, the change I've proposed here very
likely changes row layout in user tables, if we are on a platform
where TYPALIGN_INT64 != TYPALIGN_DOUBLE.  So this is a pg_upgrade
breaking change for such platforms.

Maybe this is another reason to decide that AIX isn't worth
re-supporting: if there are any AIX users out there who still care,
the prospect of a forced dump-and-reload might be enough to convince
them that they might as well migrate to a more modern platform while
they are at it.  Not sure.

If we do want to go forward with this, it would make sense to
adjust pg_control to store MAXALIGN, TYPALIGN_DOUBLE, and
TYPALIGN_INT64 separately, instead of

    /*
     * This data is used to check for hardware-architecture compatibility of
     * the database and the backend executable.  We need not check endianness
     * explicitly, since the pg_control version will surely look wrong to a
     * machine of different endianness, but we do need to worry about MAXALIGN
     * and floating-point format.  (Note: storage layout nominally also
     * depends on SHORTALIGN and INTALIGN, but in practice these are the same
     * on all architectures of interest.)
     *
     * Testing just one double value is not a very bulletproof test for
     * floating-point compatibility, but it will catch most cases.
     */
    uint32        maxAlign;        /* alignment requirement for tuples */
    double        floatFormat;    /* constant 1234567.0 */
#define FLOATFORMAT_VALUE    1234567.0

(Given that we've now pretty much locked in on IEEE float format,
I suspect floatFormat isn't pulling its weight anymore, but
perhaps that's a separate discussion.)

			regards, tom lane

  6. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-01T18:20:27Z

    I wrote:
> Here's a v2 responding to your suggestions.  0001 refactors
> att_align_nominal(), and then 0002 is nearly the same as the
> prior patch except for rebasing over that change.

I did some simple benchmarking and convinced myself that v2-0001
is a measurable win performance-wise even as things stand.
This test case spends nearly all its time in ExecEvalScalarArrayOp,
which has one of the loops improved by v2-0001:

\timing on

do $$
declare a int8[]; i int8 := 1; b bool;
begin
  while i < 10000 loop
    a[i] := i;
    i := i+1;
  end loop;
  for j in 1..10 loop
    for k in 1..10000 loop
      b := (k = any(a));
    end loop;
  end loop;
end $$;

I see about 10% improvement in runtime with 0001 compared to HEAD.
So I'm inclined to go ahead and push that patch, and then return
to considering what we're going to do about int8 vs. double
alignment.

			regards, tom lane

  7. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-02T21:46:31Z

    I pushed the att_align_nominal() refactoring, since that seems
to be a win whether we go forward with the rest of this or not.

Attached a v3 of the main patch (now again numbered 0001), plus
new work in 0002 that adds the two new alignment values to
pg_control and insists on a match before pg_upgrade'ing.
As I mentioned, this'd result in not being able to pg_upgrade
from old versions to v19 on AIX, though everywhere else it
should be fine.

0001 is the same as before except for one change: I modified the
test in CreateCast that checks whether a binary-compatible cast
is allowable.  I did that because I hit errors in cross-version
upgrade testing.  The regression tests do this:
	create type int8alias1 (..., like int8);
	create cast (int8 as int8alias1) without function;
which seems perfectly legit, but the cast fails dump/reload.
That's because we don't remember the "like" clause as such,
so the dump of int8alias1 from an existing branch will say
alignment = double, and then that doesn't match int8's new
alignment = int64.

Of course we could fix the cross-version tests by teaching
AdjustUpgrade.pm to drop these casts, but I think this is
telling us about a real usability gotcha that is likely
to bite users.  A closely related issue is the change I'd
already had to make in regression/sql/float8.sql to not
try to cast bigint to float8 without function; that used
to work but doesn't with the new typalign values.

What I did below is to instead insist on a match of the represented
alignment requirement:

-            typ1align != typ2align)
+            typalign_to_alignby(typ1align) != typalign_to_alignby(typ2align))

I'm not totally sold on that particular formulation, however.
For one thing it feels a bit too loose: on most machines it'd
allow alignment = max to match int64 or double, and I'm not
sure we want that.  For another, it makes the allowable casts
platform-dependent.  With the v3 code, we could skip changing
float8.sql on most platforms, but it'd still fail on AIX.

An alternative I've been thinking about, but haven't quite
convinced myself about, is: for pass-by-value types, why do
we need to insist on alignment match at all?  Once the value
is in Datum format it doesn't matter, and for purposes of
a binary-compatible cast the input and output are always in
Datum format.  So I was thinking about

-            typ1align != typ2align)
+            (typ1align != typ2align && !typ1byval))

which'd allow all these cases to pass without SQL-code changes.
Is there a hole in that?

An even weaker restriction would be "allow if alignby matches
or if !byval", but I'm not sure we need to go there in practice.
It'd re-introduce the problem of the test being platform dependent,
which doesn't seem great.

I'd expect to squash these into one commit in the end, but I kept
0002 separate for ease of review, since 0001 is the same as before
except for the CreateCast diff.

Thoughts?

			regards, tom lane

  8. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-03T22:29:46Z

    I wrote:
> Attached a v3 of the main patch (now again numbered 0001), plus
> new work in 0002 that adds the two new alignment values to
> pg_control and insists on a match before pg_upgrade'ing.

I've gotten cold feet about this whole idea, and no longer think
we should pursue it.  Aside from the problems already raised,
consider this: what would extensions do with existing int64-based
data types?  We don't have any provision for altering the typalign
of an existing type, and if we did it would imply doing table
rewrites (at least for cases where the change wasn't effectively
a no-op).  Worse, if such a type is created using "LIKE int8"
which has always been best practice, then whether it shows up
with align 'l' or 'd' in a new installation will depend on whether
you pg_upgrade'd or installed the extension fresh.  So that looks
like a mess waiting to happen.  Combine that with extensions that
manually set alignment = double, and never bother to update because
they can't change it and don't care anyway, and the inevitable end
result is that the 'l' and 'd' cases will be so randomly assigned
that there's not a meaningful difference after all.  Perhaps we
could have got away with such a change in the pre-pg_upgrade era,
but I think we cannot now.

If we want to re-support AIX, I think we're stuck with going back
to the old way of calculating MAXALIGN, and then re-instituting that
regression test that checked for unsafely-aligned catalog columns.
Bleah.  Still, as long as the regression test is accurate, it seems
like that'd be an annoyance not a major headache.

			regards, tom lane

  9. Re: Decoupling our alignment assumptions about int64 and double

    Andres Freund <andres@anarazel.de> — 2026-02-05T22:00:42Z

    Hi,

On 2026-02-03 17:29:46 -0500, Tom Lane wrote:
> I wrote:
> > Attached a v3 of the main patch (now again numbered 0001), plus
> > new work in 0002 that adds the two new alignment values to
> > pg_control and insists on a match before pg_upgrade'ing.
> 
> I've gotten cold feet about this whole idea, and no longer think
> we should pursue it.  Aside from the problems already raised,
> consider this: what would extensions do with existing int64-based
> data types?  We don't have any provision for altering the typalign
> of an existing type, and if we did it would imply doing table
> rewrites (at least for cases where the change wasn't effectively
> a no-op).  Worse, if such a type is created using "LIKE int8"
> which has always been best practice, then whether it shows up
> with align 'l' or 'd' in a new installation will depend on whether
> you pg_upgrade'd or installed the extension fresh.  So that looks
> like a mess waiting to happen.  Combine that with extensions that
> manually set alignment = double, and never bother to update because
> they can't change it and don't care anyway, and the inevitable end
> result is that the 'l' and 'd' cases will be so randomly assigned
> that there's not a meaningful difference after all.  Perhaps we
> could have got away with such a change in the pre-pg_upgrade era,
> but I think we cannot now.

I can't really see a way to avoid these issues either :(


> If we want to re-support AIX, I think we're stuck with going back
> to the old way of calculating MAXALIGN, and then re-instituting that
> regression test that checked for unsafely-aligned catalog columns.
> Bleah.  Still, as long as the regression test is accurate, it seems
> like that'd be an annoyance not a major headache.

I am pretty unhappy about that, I think the test and rules are just about
incomprehensible. I wonder if we ought to instead just redefine float8 to be
be aligned to 8 bytes, leaving double alone. Something like

#if ALIGNOF_DOUBLE < ALIGNOF_LONG
typedef double __attribute__((aligned(8))) float8;
#define ALIGNOF_FLOAT* ALIGNOF_LONG
#else
typedef double float8;
#define ALIGNOF_FLOAT8 ALIGNOF_DOUBLE
#endif


should do the trick.

Greetings,

Andres Freund

  10. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-05T23:32:44Z

    Andres Freund <andres@anarazel.de> writes:
> On 2026-02-03 17:29:46 -0500, Tom Lane wrote:
>> If we want to re-support AIX, I think we're stuck with going back
>> to the old way of calculating MAXALIGN, and then re-instituting that
>> regression test that checked for unsafely-aligned catalog columns.
>> Bleah.  Still, as long as the regression test is accurate, it seems
>> like that'd be an annoyance not a major headache.

> I am pretty unhappy about that, I think the test and rules are just about
> incomprehensible. I wonder if we ought to instead just redefine float8 to be
> be aligned to 8 bytes, leaving double alone.

I thought about that, but it seemed like there'd be nothing stopping
people from declaring a catalog column as "double" rather than
"float8" and thus falling into the trap anyway.  I suppose we could
put a check for that into Catalog.pm, though.

			regards, tom lane

  11. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-05T23:49:40Z

    I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I am pretty unhappy about that, I think the test and rules are just about
>> incomprehensible. I wonder if we ought to instead just redefine float8 to be
>> be aligned to 8 bytes, leaving double alone.

> I thought about that, but it seemed like there'd be nothing stopping
> people from declaring a catalog column as "double" rather than
> "float8" and thus falling into the trap anyway.  I suppose we could
> put a check for that into Catalog.pm, though.

No, scratch that: the real objection is that we can't do that unless
we are willing to break pg_upgrade on AIX.  The catalogs can't have
different alignment rules than user tables do.  Now, maybe we're
willing to go there, but it's not a pleasant prospect.

			regards, tom lane

  12. Re: Decoupling our alignment assumptions about int64 and double

    Thomas Munro <thomas.munro@gmail.com> — 2026-02-06T02:21:47Z

    On Fri, Feb 6, 2026 at 12:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2026-02-03 17:29:46 -0500, Tom Lane wrote:
> > I am pretty unhappy about that, I think the test and rules are just about
> > incomprehensible. I wonder if we ought to instead just redefine float8 to be
> > be aligned to 8 bytes, leaving double alone.
>
> I thought about that, but it seemed like there'd be nothing stopping
> people from declaring a catalog column as "double" rather than
> "float8" and thus falling into the trap anyway.  I suppose we could
> put a check for that into Catalog.pm, though.

I see that pg_upgrade is the real problem, but if that's somehow OK
("v19 is a new port, dump and restore needed!") then I wonder if
-malign=natural (which seems to be the GCC equivalent of what the
native compiler called -qalign=natural) might be an option.  Of course
that might create ABI problems for structs in library headers, IDK,
but I recall that it's not uncommon for software to tweak that sort of
thing on AIX so I wonder if system headers might have their own
alignment attributes to cope... and if some third party library breaks
(how many libraries actually deal in double though?), I wonder if it's
possible to pragma/push/whatever your way around it...

  13. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-06T19:50:05Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> I see that pg_upgrade is the real problem, but if that's somehow OK
> ("v19 is a new port, dump and restore needed!") then I wonder if
> -malign=natural (which seems to be the GCC equivalent of what the
> native compiler called -qalign=natural) might be an option.

I experimented with that.  It's spelled -malign-natural, and it
does change ALIGNOF_DOUBLE from 4 to 8.

> Of course
> that might create ABI problems for structs in library headers,

Yeah, that.  Perhaps we'd get away with it, but I think Andres'
suggestion of putting an alignment spec into typedef float8
has a far smaller blast radius.  (I tested that too, and it
seems to work.)

Side observation: either approach sets ALIGNOF_DOUBLE = 8 in both
32-bit and 64-bit builds, while ALIGNOF_INT64_T is 8 in any case.
I still think we should deprecate 32-bit AIX builds because of the
hassles around finding address space for loadable modules; but
the data alignment situation isn't different.

Of course the $64 question is whether we can get away with requiring a
dump and reload (and how we'd make pg_upgrade enforce that if we did,
considering that existing installations' pg_control will only surface
the value of MAXALIGN not DOUBLEALIGN).

			regards, tom lane

  14. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-06T22:05:06Z

    I wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
>> I see that pg_upgrade is the real problem, but if that's somehow OK
>> ("v19 is a new port, dump and restore needed!") then I wonder if
>> -malign=natural (which seems to be the GCC equivalent of what the
>> native compiler called -qalign=natural) might be an option.

> Of course the $64 question is whether we can get away with requiring a
> dump and reload (and how we'd make pg_upgrade enforce that if we did,
> considering that existing installations' pg_control will only surface
> the value of MAXALIGN not DOUBLEALIGN).

Your thought of maybe applying some compiler ju-jitsu led me to a
different research direction: if we can get the compiler to lay out
the catalog structs as if DOUBLEALIGN and LONGALIGN were 4, then
problem solved without need for any user-table compatibility break.
And we can: it looks like inserting

	#pragma pack(4)

before each catalog struct definition (and then "#pragma pack()"
afterwards to restore the normal rules) would do the trick.
This is probably quite gcc-specific, but if we're tossing xlc
overboard that doesn't matter.

Ideally we'd find a way to embed that in the CATALOG macros rather
than needing explicit AIX-droppings all over include/catalog/*.h.
But I'm not sure that it's possible to put a #pragma in a macro.
Even if we can't be neat about it, this is seeming like an attractive
line of inquiry.

			regards, tom lane

  15. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-07T02:42:52Z

    I wrote:
> Your thought of maybe applying some compiler ju-jitsu led me to a
> different research direction: if we can get the compiler to lay out
> the catalog structs as if DOUBLEALIGN and LONGALIGN were 4, then
> problem solved without need for any user-table compatibility break.
> And we can: it looks like inserting
> 	#pragma pack(4)
> before each catalog struct definition (and then "#pragma pack()"
> afterwards to restore the normal rules) would do the trick.

Here's a POC patch to fix AIX's alignment problems that way.
I feel much better about this approach than the other one ...

			regards, tom lane

  16. RE: Decoupling our alignment assumptions about int64 and double

    Aditya Kamath <aditya.kamath1@ibm.com> — 2026-02-10T09:14:16Z

    Hi Tom and community members,

>Here's a POC patch to fix AIX's alignment problems that way.
>I feel much better about this approach than the other one …



Thank you for this POC patch.

We built the master branch with this POC patch plus meson and GNU build development patches for AIX.

We tested this in our AIX environment using DOUBLE PRECISION and BIGINT columns to verify that pg_upgrade succeeds. We first created a PostgreSQL 15 database cluster, populated it with sample records, and then upgraded it to a master-branch build that includes this patch. The upgrade completed successfully.

Below are the output snapshots and TAP test results from the master branch with this patch from our run.


pg_upgrade -b $HOME/postgres_15/postgres/install/usr/local/pgsql/bin/ -B $HOME/postgres/install/usr/local/pgsql/bin/ -d $HOME/data15 -D $HOME/datamaster --check
Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok
Checking database connection settings                         ok
Checking database user is the install user                    ok
Checking for prepared transactions                            ok
Checking for contrib/isn with bigint-passing mismatch         ok
Checking data type usage                                      ok
Checking for not-null constraint inconsistencies              ok
Checking for uses of gist_inet_ops/gist_cidr_ops              ok
Checking for presence of required libraries                   ok
Checking database user is the install user                    ok
Checking for prepared transactions                            ok
Checking for new cluster tablespace directories               ok

*Clusters are compatible*

Schema of the table:
CREATE TABLE sensor_readings (
    id BIGSERIAL PRIMARY KEY,
    measurement_value DOUBLE PRECISION,
    count_64 BIGINT,
    note TEXT
);


These were the records before the upgrade in PostgreSQL version 15,
testdb=# select * from sensor_readings;
 id | measurement_value | count_64 |    note
----+-------------------+----------+------------
  1 |             12.45 |     1001 | Reading 1
  2 |             15.02 |     1002 | Reading 2
  3 |             18.77 |     1003 | Reading 3
  4 |             21.05 |     1004 | Reading 4
  5 |             25.61 |     1005 | Reading 5
  6 |             28.43 |     1006 | Reading 6
  7 |             30.12 |     1007 | Reading 7
  8 |             31.98 |     1008 | Reading 8
  9 |             33.47 |     1009 | Reading 9
 10 |             35.22 |     1010 | Reading 10

And then after pg_upgrade in Postgresql master branch
testdb=# select * from sensor_readings;
 id | measurement_value | count_64 |    note
----+-------------------+----------+------------
  1 |             12.45 |     1001 | Reading 1
  2 |             15.02 |     1002 | Reading 2
  3 |             18.77 |     1003 | Reading 3
  4 |             21.05 |     1004 | Reading 4
  5 |             25.61 |     1005 | Reading 5
  6 |             28.43 |     1006 | Reading 6
  7 |             30.12 |     1007 | Reading 7
  8 |             31.98 |     1008 | Reading 8
  9 |             33.47 |     1009 | Reading 9
 10 |             35.22 |     1010 | Reading 10


============== GNU build TAP test results =============
t/035_standby_logical_decoding.pl ..... skipped: Injection points not supported by this build
t/036_truncated_dropped.pl ............ ok
t/037_invalid_database.pl ............. ok
t/038_save_logical_slots_shutdown.pl .. ok
t/039_end_of_wal.pl ................... ok
t/040_standby_failover_slots_sync.pl .. ok
t/041_checkpoint_at_promote.pl ........ skipped: Injection points not supported by this build
t/042_low_level_backup.pl ............. ok
t/043_no_contrecord_switch.pl ......... ok
t/044_invalidate_inactive_slots.pl .... skipped: Injection points not supported by this build
t/045_archive_restartpoint.pl ......... ok
t/046_checkpoint_logical_slot.pl ...... skipped: Injection points not supported by this build
t/047_checkpoint_physical_slot.pl ..... skipped: Injection points not supported by this build
t/048_vacuum_horizon_floor.pl ......... ok
t/049_wait_for_lsn.pl ................. ok
t/050_redo_segment_missing.pl ......... skipped: Injection points not supported by this build
t/051_effective_wal_level.pl .......... ok
All tests successful.
Files=50, Tests=584, 328 wallclock secs ( 0.11 usr  0.04 sys + 11.20 cusr 16.44 csys = 27.79 CPU)
Result: PASS

============ Meson test TAP results ====================
355/361 postgresql:pg_basebackup / pg_basebackup/040_pg_createsubscriber                         OK               74.88s   54 subtests passed
356/361 postgresql:recovery / recovery/027_stream_regress                                        OK              111.07s   11 subtests passed
357/361 postgresql:pg_upgrade / pg_upgrade/006_transfer_modes                                    OK              114.24s   40 subtests passed
358/361 postgresql:pg_verifybackup / pg_verifybackup/003_corruption                              OK               70.04s   92 subtests passed
359/361 postgresql:subscription / subscription/100_bugs                                          OK               27.44s   17 subtests passed
360/361 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade                                        OK              115.77s   19 subtests passed
361/361 postgresql:pg_basebackup / pg_basebackup/010_pg_basebackup                               OK               86.86s   200 subtests passed

Ok:                 329
Expected Fail:      0
Fail:               0
Unexpected Pass:    0
Skipped:            32
Timeout:            0

Full log written to /home/buildusr/postgres/build/meson-logs/testlog.txt

===============

Have a nice day ahead.

Thanks and regards,
Aditya.

  17. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-10T20:52:18Z

    Aditya Kamath <Aditya.Kamath1@ibm.com> writes:
> We built the master branch with this POC patch plus meson and GNU build development patches for AIX.
> We tested this in our AIX environment using DOUBLE PRECISION and BIGINT columns to verify that pg_upgrade succeeds. We first created a PostgreSQL 15 database cluster, populated it with sample records, and then upgraded it to a master-branch build that includes this patch. The upgrade completed successfully.

Cool, thanks for testing.

Here's a fleshed-out version of that patch.  I propagated the
BEGIN/END_CATALOG_STRUCT macros into all the catalog headers
and removed the for-test-purposes-only column rearrangement in
pg_subscription.h.  I also elected to use the push/pop variants of the
pack pragma.  This makes no difference today, since we're not using
that pragma elsewhere, but conceivably it'll make this easier to work
with in future.  It's otherwise the same except for a bit more
comment-smithing.

			regards, tom lane

  18. Re: Decoupling our alignment assumptions about int64 and double

    Thomas Munro <thomas.munro@gmail.com> — 2026-02-10T21:24:56Z

    > But now that we've agreed to toss xlc support
> out the window,

We weren't the only ones, apparently...  I don't know the details but
it would be surprising if this stuff doesn't work on this tool chain:

https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.4?topic=new-enhanced-llvm-clang-support

  19. Re: Decoupling our alignment assumptions about int64 and double

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-10T22:23:03Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> it would be surprising if this stuff doesn't work on this tool chain:

> https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.4?topic=new-enhanced-llvm-clang-support

Yeah, I'd be interested in trying that toolchain once we have a
finished port on gcc.

			regards, tom lane

  20. RE: Decoupling our alignment assumptions about int64 and double

    Aditya Kamath <aditya.kamath1@ibm.com> — 2026-02-11T10:41:09Z

    Hi Tom and community members,

>Cool, thanks for testing.

>Here's a fleshed-out version of that patch.  I propagated the
>BEGIN/END_CATALOG_STRUCT macros into all the catalog headers
>and removed the for-test-purposes-only column rearrangement in
>pg_subscription.h.  I also elected to use the push/pop variants of the
>pack pragma.  This makes no difference today, since we're not using
>that pragma elsewhere, but conceivably it'll make this easier to work
>with in future.  It's otherwise the same except for a bit more
>comment-smithing.

We tested the patch "v5-0001-Cope-with-AIX-s-alignment-woes-by-using-_Pragma-p.patch". Thank you for the same. We were able to upgrade the database from pg15 to the latest master branch having this patch and our GNU and Meson patches.

Thank you once again for the patch and we liked the idea.

Attaching the results of the same below,


==================Meson test case run with TAP test  ====================

354/361 postgresql:recovery / recovery/033_replay_tsp_drops                                      OK              104.35s   3 subtests passed
355/361 postgresql:pg_basebackup / pg_basebackup/040_pg_createsubscriber                         OK               74.12s   54 subtests passed
356/361 postgresql:recovery / recovery/027_stream_regress                                        OK              108.43s   11 subtests passed
357/361 postgresql:pg_upgrade / pg_upgrade/006_transfer_modes                                    OK              111.43s   40 subtests passed
358/361 postgresql:pg_verifybackup / pg_verifybackup/003_corruption                              OK               70.00s   92 subtests passed
359/361 postgresql:subscription / subscription/100_bugs                                          OK               27.98s   17 subtests passed
360/361 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade                                        OK              113.34s   19 subtests passed
361/361 postgresql:pg_basebackup / pg_basebackup/010_pg_basebackup                               OK               85.73s   200 subtests passed

Ok:                 330
Expected Fail:      0
Fail:               0
Unexpected Pass:    0
Skipped:            31
Timeout:            0

Full log written to /home/buildusr/postgres/build/meson-logs/testlog.txt

==================GNU build test case run with TAP test  ====================


t/043_no_contrecord_switch.pl ......... ok
t/044_invalidate_inactive_slots.pl .... skipped: Injection points not supported by this build
t/045_archive_restartpoint.pl ......... ok
t/046_checkpoint_logical_slot.pl ...... skipped: Injection points not supported by this build
t/047_checkpoint_physical_slot.pl ..... skipped: Injection points not supported by this build
t/048_vacuum_horizon_floor.pl ......... ok
t/049_wait_for_lsn.pl ................. ok
t/050_redo_segment_missing.pl ......... skipped: Injection points not supported by this build
t/051_effective_wal_level.pl .......... ok
All tests successful.
Files=50, Tests=584, 326 wallclock secs ( 0.11 usr  0.04 sys + 11.14 cusr 16.39 csys = 27.68 CPU)
Result: PASS
gmake[2]: Leaving directory '/home/buildusr/postgres/src/test/recovery'
gmake[1]: Leaving directory '/home/buildusr/postgres/src/test'

=========== Database records before upgrade via Postgres 15  ==============
bash-5.2$ pg_ctl --version
pg_ctl (PostgreSQL) 15.15

These were the records before the upgrade in PostgreSQL version 15,
testdb=# select * from sensor_readings;
 id | measurement_value | count_64 |    note
----+-------------------+----------+------------
  1 |             12.45 |     1001 | Reading 1
  2 |             15.02 |     1002 | Reading 2
  3 |             18.77 |     1003 | Reading 3
  4 |             21.05 |     1004 | Reading 4
  5 |             25.61 |     1005 | Reading 5
  6 |             28.43 |     1006 | Reading 6
  7 |             30.12 |     1007 | Reading 7
  8 |             31.98 |     1008 | Reading 8
  9 |             33.47 |     1009 | Reading 9
 10 |             35.22 |     1010 | Reading 10


============================= Data base recovery check and DB records after upgrade ==========================

bash-5.2$ pg_ctl --version
pg_ctl (PostgreSQL) 19devel

bash-5.2$ pg_upgrade -b $HOME/postgres_15/postgres/install/usr/local/pgsql/bin/ -B $HOME/postgres/install/usr/local/pgsql/bin/ -d $HOME/data15 -D $
HOME/datamaster --check
Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok
Checking database connection settings                         ok
Checking database user is the install user                    ok
Checking for prepared transactions                            ok
Checking for contrib/isn with bigint-passing mismatch         ok
Checking data type usage                                      ok
Checking for not-null constraint inconsistencies              ok
Checking for uses of gist_inet_ops/gist_cidr_ops              ok
Checking for presence of required libraries                   ok
Checking database user is the install user                    ok
Checking for prepared transactions                            ok
Checking for new cluster tablespace directories               ok

*Clusters are compatible*





====================== Data base records after upgrade Postgres Master branch ====================

testdb=# select * from sensor_readings;
id | measurement_value | count_64 |    note
----+-------------------+----------+——————
1 |             12.45 |     1001 | Reading 1
2 |             15.02 |     1002 | Reading 2
3 |             18.77 |     1003 | Reading 3
4 |             21.05 |     1004 | Reading 4
5 |             25.61 |     1005 | Reading 5
6 |             28.43 |     1006 | Reading 6
7 |             30.12 |     1007 | Reading 7
8 |             31.98 |     1008 | Reading 8
9 |             33.47 |     1009 | Reading 9
10 |             35.22 |     1010 | Reading 10


>Thomas Munro <thomas.munro@gmail.com<mailto:thomas.munro@gmail.com>> writes:
>> it would be surprising if this stuff doesn't work on this tool chain:
>> https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.4?topic=new-enhanced-llvm-clang-support
>Yeah, I'd be interested in trying that toolchain once we have a
>finished port on gcc.

Sure, Tom and Thomas. Once we complete the GCC part of porting we can setup this compiler to use in the p9-aix1-postgres1 OSU lab node. Let me know if you need access to the same. We can provide the access. This has better config in the OSU lab than the GCC farm LPAR.

Have a nice day ahead.

Thanks and regards,
Aditya.