On Thu, Feb 12, 2026 at 1:17 AM Maxim Orlov <[email protected]> wrote: > 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.
Yes, I think I'm mostly against that. I don't think there is much of a real use case for allowing the XID distance back to the oldest running transaction to exceed ~2 billion. Normally, long before a database gets to that point, the bloat has become so bad that the database has become unusable. There are exceptions, of course. If you have a workload where nearly all of the dead tuples are cleaned up by HOT-pruning, you might be able to survive this sort of scenario, but it's a pretty corner case, because most people are not going to have a workload where absolutely 100% of the updates are HOT. If we could allow transactions to run for billions of XIDs without creating any other problems, I suppose that would be fine, but this patch definitely doesn't achieve that, and I don't really think any patch can achieve that. As Heikki also says, the real benefit of doing something like this in my mind is to reduce the need for or the impact of aggressive vacuuming. If we are always able to determine a proper epoch for every tuple, no matter how old, then aggressive vacuums are only needed to keep the size of CLOG down, not to keep the database running. We can get that benefit without changing the in-memory tuple representation or the size of TransactionId, and, as Heikki said better than I can, that could make for a smaller patch with a better chance of actually going somewhere. Nobody -- certainly not me -- wants all the work you've done here to go to waste; I believe we are all united in wanting to get a benefit out of it. But if the patch is too big and does too many things, it won't make any progress even if everyone likes all of those things, and even more so if some of them are controversial. -- Robert Haas EDB: http://www.enterprisedb.com
