RE: Decoupling our alignment assumptions about int64 and double - Mailing list pgsql-hackers
| From | Aditya Kamath |
|---|---|
| Subject | RE: Decoupling our alignment assumptions about int64 and double |
| Date | |
| Msg-id | LV8PR15MB6488D3907B0A711699B404ECD663A@LV8PR15MB6488.namprd15.prod.outlook.com Whole thread |
| In response to | Re: Decoupling our alignment assumptions about int64 and double (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-hackers |
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
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> 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.
>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.
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.
pgsql-hackers by date: