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

From wenhui qiu
Subject Re: Add 64-bit XIDs into PostgreSQL 15
Date
Msg-id CAGjGUA+1T=mwA4tp72eWX+jCsADsgr-B4xVyhAKw=4VhLqOT2w@mail.gmail.com
Whole thread
In response to Re: Add 64-bit XIDs into PostgreSQL 15  (Maxim Orlov <orlovmg@gmail.com>)
List pgsql-hackers
HI Maxim
> The aim of this patch is to make Postgres support 64-bit XIDs.
> This is why the TransactionID type size increases from 4 to 8 bytes.
>It also has an effect on the proc array, allowing two transactions that
> that are more than 2 billion XIDs apart to run at the same time.

> You couldn't store tuples that were more than 2 billion XIDs apart
> on a single heap page. That is correct. However, this annoying 
> limitation comes only from the page format. Moreover, it looks like
> as long as we have a page format with a base, we will not be able 
> to bypass this limitation. Yet, running transactions far apart is
> totally accepted.
Yes ,Furthermore, this approach is not unprecedented. Several
PostgreSQL-derived systems have already adopted 64-bit transaction IDs

Thanks

On Tue, Feb 10, 2026 at 2:19 PM Maxim Orlov <orlovmg@gmail.com> wrote:

On Mon, 9 Feb 2026 at 18:03, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

The point is that we still do not want to use FullTransactionID
everywhere. Only in some places related to visibility checks that need
to deal with XIDs stored on sidk, like heapam_visibility.c and clog.c,
and it will probably spill over to some other places. But things like
the proc array can continue to use 32-bit XIDs.

We will still have the limitation that you cannot have two transactions
*running* that are more than 2 billion XIDs apart. I think that's fine,
and we should not try to lift that limitation as part of this patch.

The aim of this patch is to make Postgres support 64-bit XIDs.
This is why the TransactionID type size increases from 4 to 8 bytes.
It also has an effect on the proc array, allowing two transactions that
that are more than 2 billion XIDs apart to run at the same time.

You couldn't store tuples that were more than 2 billion XIDs apart
on a single heap page. That is correct. However, this annoying
limitation comes only from the page format. Moreover, it looks like
as long as we have a page format with a base, we will not be able 
to bypass this limitation. Yet, running transactions far apart is
totally accepted.


--
Best regards,
Maxim Orlov.

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Miscellaneous message fixes
Next
From: Shinya Kato
Date:
Subject: Re: Use pg_current_xact_id() instead of deprecated txid_current()