Re: Add 64-bit XIDs into PostgreSQL 15
Maxim Orlov <orlovmg@gmail.com>
From: Maxim Orlov <orlovmg@gmail.com>
To: Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>
Cc: wenhui qiu <qiuwenhuifx@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Evgeny <evorop@gmail.com>
Date: 2025-05-16T14:54:50Z
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
- v61-0002-Use-64-bit-FullTransactionId-instead-of-Epoch-xi.patch (application/octet-stream) patch v61-0002
- v61-0004-Use-64-bit-GUCs.patch (application/octet-stream) patch v61-0004
- v61-0001-Use-64-bit-format-to-output-XIDs.patch (application/octet-stream) patch v61-0001
- v61-0003-Use-64-bit-SLRU-pages-in-callers.patch (application/octet-stream) patch v61-0003
- v61-0007-NormalTransactionIdToShort-should-distinct-multi.patch (application/octet-stream) patch v61-0007
- v61-0008-Add-initdb-option-to-initialize-cluster-with-non.patch (application/octet-stream) patch v61-0008
- v61-0005-Use-64-bit-XIDs.patch (application/octet-stream) patch v61-0005
- v61-0006-README.XID64.patch (application/octet-stream) patch v61-0006
On Wed, 26 Mar 2025 at 19:18, Evgeny Voropaev < evgeny.voropaev@tantorlabs.com> wrote: > Hello hackers! > > The actual version of the xid64 patch is attached. The patch has been > rebased onto the master branch (1eb399366ed, 2025-03-26). Thank you for the rebase! I appreciate you wanting to help. In fact, I update this patch almost every month, and I am aware of the aforementioned flaws (as well as a few others). I don't post updates to the mailing list because I intend to rebuild this patch, as some aspects of it are no longer relevant. If all goes well, I'll complete it in the coming weeks. Unfortunately, it is now evident to me that the patch in its current form cannot be committed. The only way to go is to do it in an increment way. Step by step. As previously said, it is best to focus on [0], which introduces 64-bit mxoff. However, as the primary developer of this patch set, I respectfully request that you refrain from refactoring the code here, as this hampers future rebases, given the patch's size and complexity. We'll gladly take any refactoring recommendations when and if the patch is ready to commit. However, if you discover any bugs, I advise you to report them in this thread first and, if you can, include a reproduction. It would be extremely helpful. Otherwise, we risk ending up with the mess here. As for the bug-fixes part. 1) Yes, heapam_tuple_satisfies_snapshot needs to re-copy XIDs from the page for a tuple, and as an ad-hoc fix, this will work, but a proper fix should consider all cases (present and foreseeable in the future); thus, HeapTupleSatisfies* functions should do this. This is not easy because we must know if this particular tuple is from the TOAST relation or not. Straightforward throwing through a function argument would be a very ugly solution. I'll try to address these issues in the next iteration. 2) Fix for DecodeUpdate is bogus. The datalen is not calculated properly. 3) Fix "Removed the management of repairing fragmentation". I don't really get it. In my rebase, it works as it should, and I don't understand why it may be removed. Overall, it looks like there is a problem with this rebase, unfortunately. PFA rebased @ dbf42b84ac patch set. [0] https://commitfest.postgresql.org/patch/5205/ -- Best regards, Maxim Orlov.