Re: Add 64-bit XIDs into PostgreSQL 15

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: Evgeny Voropaev <evgeny(dot)voropaev(at)tantorlabs(dot)com>
Cc: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Evgeny <evorop(at)gmail(dot)com>
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Date: 2025-05-16 14:54:50
Message-ID: CACG=ezYFip76d7r1MMkb3zYiC=x+sgrSd6_aBWAtwtui8MnX-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 26 Mar 2025 at 19:18, Evgeny Voropaev <
evgeny(dot)voropaev(at)tantorlabs(dot)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.

Attachment Content-Type Size
v61-0002-Use-64-bit-FullTransactionId-instead-of-Epoch-xi.patch application/octet-stream 22.3 KB
v61-0004-Use-64-bit-GUCs.patch application/octet-stream 30.2 KB
v61-0001-Use-64-bit-format-to-output-XIDs.patch application/octet-stream 146.5 KB
v61-0003-Use-64-bit-SLRU-pages-in-callers.patch application/octet-stream 4.2 KB
v61-0007-NormalTransactionIdToShort-should-distinct-multi.patch application/octet-stream 5.5 KB
v61-0008-Add-initdb-option-to-initialize-cluster-with-non.patch application/octet-stream 31.2 KB
v61-0005-Use-64-bit-XIDs.patch application/octet-stream 771.6 KB
v61-0006-README.XID64.patch application/octet-stream 7.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-05-16 15:06:46 Document default values for pgoutput options + fix missing initialization for "origin"
Previous Message Daniel Gustafsson 2025-05-16 14:40:21 Re: Align wording on copyright organization