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 <[email protected]> wrote: > > On Mon, 9 Feb 2026 at 18:03, Heikki Linnakangas <[email protected]> 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. >
