Re: Add 64-bit XIDs into PostgreSQL 15

On Thu, Feb 12, 2026 at 1:17 AM Maxim Orlov <orlovmg@gmail.com> 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