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

From Maxim Orlov
Subject Re: Add 64-bit XIDs into PostgreSQL 15
Date
Msg-id CACG=ezYFip76d7r1MMkb3zYiC=x+sgrSd6_aBWAtwtui8MnX-w@mail.gmail.com
Whole thread Raw
In response to Re: Add 64-bit XIDs into PostgreSQL 15  (Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>)
List pgsql-hackers

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.
Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Align wording on copyright organization
Next
From: Fujii Masao
Date:
Subject: Document default values for pgoutput options + fix missing initialization for "origin"