Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, 10 Feb 2026 at 17:54, Robert Haas <robertmhaas@gmail.com> wrote:

> Well, what three committers are telling you is that this approach has
> zero chance of being accepted.
>

Yes, thank you; I do understand. I expressed an unpopular opinion: all
XIDs in Potsgres should be 64-bit. And it is quite evident to me that
no one on the committers' side supports it. But, ideally, I'd like to
know why you have this opinion and what the reasons against it are,
besides the fact that this will increase the size of the database.

According, Michael Stonebraker, I guess he is a professor two, in [0] that:
Every tuple has an immutable unique identifier (IID) that is assigned at
tuple creation time and never changes. This is a 64 bit quantity assigned
internally by POSTGRES.

It appears that this was lost at a later time, and we are now dealing
with 32-bit XIDs.


There are other things about the patch set you might have more luck
> getting people to change their mind. You can offer arguments why your
> approach is better, or you can argue that we've misunderstood the
> situation and the competing approaches are less viable than we
> believe. And it's not like we're all three of us in lock step about
> every single design decision here. But I would respectfully suggest
> that you save arguing for the cases where there is a truly debatable
> point. I typically find that I, and other people who want to get their
> patches committed, generally need to accept 80-90% of the feedback
> they get from pgsql-hackers and put in the effort to reshape the patch
> accordingly, and then maybe 10-20% of it you can argue about and say
> "well, actually, I see it differently."


Please make this clear for me. Do I understand correctly that you
oppose Postgres' ability to handle transactions more than an epoch
apart? For me, this is more than just an argument; it is the essence
of this patch.

As I mentioned above, I'm currently revising the patch and will, of
course, consider your suggestions. However, without converting, let's say,
procarray to 64-bit, the whole point of the transition is somehow lost
on me. So it's essentially a change that will simplify the logic for
handling transaction IDs in some places while lowering page space and
requiring additional epoch synchronization with the XIDs of every tuple.

[0] https://dsf.berkeley.edu/papers/ERL-M85-95.pdf

-- 
Best regards,
Maxim Orlov.