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 →
  1. Add SLRU tests for 64-bit page case

  2. Make use FullTransactionId in 2PC filenames

  3. Use larger segment file names for pg_notify

  4. Index SLRUs by 64-bit integers rather than by 32-bit integers

Attachments

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.