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