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=ezZ3gUTeD00P8ADm8B5xdFyDQqdXBMbkcoWJ2wvg0d749A@mail.gmail.com
Whole thread
In response to Re: Add 64-bit XIDs into PostgreSQL 15  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Add 64-bit XIDs into PostgreSQL 15
Re: Add 64-bit XIDs into PostgreSQL 15
List pgsql-hackers

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: Ashutosh Bapat
Date:
Subject: Re: Changing shared_buffers without restart
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Miscellaneous message fixes