Re: Add 64-bit XIDs into PostgreSQL 15

Finnerty, Jim <jfinnert@amazon.com>

From: "Finnerty, Jim" <jfinnert@amazon.com>

To: Alexander Korotkov <aekorotkov@gmail.com>

Cc: Maxim Orlov <orlovmg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2022-01-07T15:53:51Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add SLRU tests for 64-bit page case
- a60b8a58f435 17.0 landed
Make use FullTransactionId in 2PC filenames
- 5a1dfde8334b 17.0 landed
Use larger segment file names for pg_notify
- 2cdf131c46e6 17.0 landed
Index SLRUs by 64-bit integers rather than by 32-bit integers
- 4ed8f0913bfd 17.0 landed

Re:    The "prepare" approach was the first tried.
    https://github.com/postgrespro/pg_pageprep
    But it appears to be very difficult and unreliable.  After investing
    many months into pg_pageprep, "double xmax" approach appears to be
    very fast to implement and reliable.

I'd still like a plan to retire the "double xmax" representation eventually.  Previously I suggested that this could be done as a post-process, before upgrade is complete, but that could potentially make upgrade very slow. 

Another way to retire the "double xmax" representation eventually could be to disallow "double xmax" pages in subsequent major version upgrades (e.g. to PG16, if "double xmax" pages are introduced in PG15).  This gives the luxury of time after a fast upgrade to convert all pages to contain the epochs, while still providing a path to more maintainable code in the future.