Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Feb 10, 2026 at 1:19 AM Maxim Orlov <orlovmg@gmail.com> wrote:
> 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.

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

Now, of course, none of us have any control over what you or anyone
else chooses to submit. It's perfectly possible to keep submitting
this patch set with this design choice. But I do not think anyone will
ever commit it, and if by chance someone did, there would be an
immediate outcry and it would certainly end up getting reverted. This
is kind of what I meant in my earlier message when I said this:

> It's worth considering why this patch set hasn't made more progress up
> until this point. It could be simply that the patch set is big and
> nobody quite has time to review it thorougly. However, it's my
> observation that when there's a patch set floating around for years
> that fixes a problem that other committers know to be important and
> yet it doesn't get committed, it's often a sign that some committers
> have taken a peek at the patch set and don't believe that it's taking
> the right approach, or don't believe the code is viable, or believe
> that fixing the code to be viable would require way more work than
> they can justify putting into someone else's patch.

Subsequent discussion has revealed that this speculation on my part
was right on point: it seems pretty clear that there are several key
design points on which Andres, Heikki, and I are more or less aligned
where what the patch does is something quite different. Unless that
changes, this really has no future. Now, of course, it could change in
two ways: the patch set could match what other people want to happen,
or people's ideas about what they want to have happen could change to
match the patch set. But I think you're going to find that it's
utterly impossible to convince anyone here that redefining
TransactionId to be what FullTransactionId already is is the right way
forward. Every professor I had in college would have taken style
points off for that decision, and as professionals, our standards for
code quality ought to be higher, not lower, than what is expected in a
college classroom.

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." If that's a frustrating thing
to hear, I completely understand. If you don't want to pursue getting
this committed, that's up to you. But arguing about whether this
particular change is the right way forward is just going to get people
to stick this thread back in a mental bucket labeled "patch has no
future, author is never going to fix it, might as well ignore."

--
Robert Haas
EDB: http://www.enterprisedb.com