| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Maxim Orlov <orlovmg(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-12 18:52:30 |
| Message-ID: | aY4g1fOhnhq55yRc@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-02-09 08:40:48 -0500, Robert Haas wrote:
> On Sun, Feb 8, 2026 at 12:21 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On the topic of pd_prune_xid - I've been wondering if, instead of the double
> > xmax approach, the high bits of the 64bit xid could be stored in pd_prune_xid,
> > signified by a flag on the page indicating so.
>
> We potentially have both XIDs and MXIDs to worry about, though.
I don't think mxids are a problem for the case of needing to update a page
that doesn't have space for the new pd_special region (with both xid and mxid
epoch), because you can always can just replace mxids with the underlying xids
when you're in that situation, they have to be old enough for that to be
possible. Or you could even create new multixacts, but I don't think that
should ever be needed.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-02-12 19:00:00 | Re: BUG: Former primary node might stuck when started as a standby |
| Previous Message | Zsolt Parragi | 2026-02-12 18:51:33 | Re: Improve OAuth discovery logging |