On Tue, Feb 10, 2026 at 1:19 AM Maxim Orlov <[email protected]> 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
