On Tue, 10 Feb 2026 at 17:54, Robert Haas <[email protected]> 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.
