| From: | wenhui qiu <qiuwenhuifx(at)gmail(dot)com> |
|---|---|
| To: | Maxim Orlov <orlovmg(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Evgeny Voropaev <evgeny(dot)voropaev(at)tantorlabs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Subject: | Re: Add 64-bit XIDs into PostgreSQL 15 |
| Date: | 2026-02-10 06:32:06 |
| Message-ID: | CAGjGUA+1T=mwA4tp72eWX+jCsADsgr-B4xVyhAKw=4VhLqOT2w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)gmail(dot)com> wrote:
>
> On Mon, 9 Feb 2026 at 18:03, Heikki Linnakangas <hlinnaka(at)iki(dot)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.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shinya Kato | 2026-02-10 06:38:38 | Re: Use pg_current_xact_id() instead of deprecated txid_current() |
| Previous Message | Kyotaro Horiguchi | 2026-02-10 06:18:53 | Re: Miscellaneous message fixes |