Re: Add 64-bit XIDs into PostgreSQL 15 - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: Add 64-bit XIDs into PostgreSQL 15
Date
Msg-id CALT9ZEGhD83LetG44j4-bz85HGd+6nKbH-gThQd+whQnEQqPcw@mail.gmail.com
Whole thread Raw
In response to Re: Add 64-bit XIDs into PostgreSQL 15  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: Add 64-bit XIDs into PostgreSQL 15  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Hi, Hackers! 
Hi! Here is updated version of the patch, based on Alexander's ver16. 
I'd like to add a few quick notes on what's been done in v17.

Patches 0001 and 0002 that are planned to be committed to PG15 are almost unchanged with the exception of one unnecessary cast in 0002 removed. 

We've also addressed several issues in patch 0005 (which is planned for PG16):
- The bug with frozen xids after pg_upgrade, reported by Justin [1]
- Added proper processing of double xmax pages in HeapPageSetPruneXidInternal()
- Fixed xids comparison. Initially in the patch it was changed to simple < <= => > for 64 bit values. Now v17 patch has returned this to the way similar to what is used in STABLE for 32-bit xids, but using modulus-64 numeric ring. The main goal of this change was to fix SRLU tests that were mentioned by Alexander to have been disabled. We've fixed and enabled most of them, but some of them are still need to be fixed and enabled.

Also, we've pgindent-ed all the patches.

As patches that are planned to be delivered to PG15 are almost unchanged, I completely agree with Alexander's plan to consider these patches (0001 and 0002) as RfC.

All activity, improvement, review, etc. related to the whole patchset is also very much appreciated. Big thanks to Alexander for working on the patch set!

Also, the patch v17 (0005) returns SLRU_PAGES_PER_SEGMENT to the previous value of 32.

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_statements and "IN" conditions
Next
From: Mark Dilger
Date:
Subject: Re: role self-revocation