Decoupling our alignment assumptions about int64 and double

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

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

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

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

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

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

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

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

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

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

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...

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

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

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

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.

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

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

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

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.