Re: Add 64-bit XIDs into PostgreSQL 15
Maxim Orlov <orlovmg@gmail.com>
From: Maxim Orlov <orlovmg@gmail.com>
To: Thom Brown <thom@linux.com>
Cc: Zhang Mingli <zmlpostgres@gmail.com>,
Michael Paquier <michael@paquier.xyz>, Justin Pryzby <pryzby@telsasoft.com>, Dilip Kumar <dilipbalaut@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>,
Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers@lists.postgresql.org, Stephen Frost <sfrost@snowman.net>, Alexander Korotkov <aekorotkov@gmail.com>,
Andres Freund <andres@anarazel.de>, Ilya Anfimov <ilan@tzirechnoy.com>
Date: 2022-11-14T13:56:07Z
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
Attachments
- v50-0004-Use-64-bit-pages-representation-in-SLRU-callers.patch (application/octet-stream) patch v50-0004
- v50-0001-Use-64-bit-numbering-of-SLRU-pages.patch (application/octet-stream) patch v50-0001
- v50-0005-Add-initdb-option-to-initialize-cluster-with-non.patch (application/octet-stream) patch v50-0005
- v50-0003-Use-64-bit-FullTransactionId-instead-of-Epoch-xi.patch (application/octet-stream) patch v50-0003
- v50-0002-Use-64-bit-format-to-output-XIDs.patch (application/octet-stream) patch v50-0002
- v50-0007-Use-64-bit-GUCs.patch (application/octet-stream) patch v50-0007
- v50-0006-README.XID64.patch (application/octet-stream) patch v50-0006
- v50-0008-Use-64-bit-XIDs.patch (application/octet-stream) patch v50-0008
> > > 0008 needs a rebase. heapam.h and catversion.h are failing. > > Regards > > Thom > Thanks, done! Also add copying of the xmin and xmax while page is locked. In heapgetpage we have to copy tuples xmin and xmax while we're holding a lock. Since we do not hold a lock after that, values of xmin or xmax may be changed, and we may get incorrect values of those fields. This affects only the scenario when the user select xmin or xmax "directly" by SQL query, AFAICS. -- Best regards, Maxim Orlov.