Re: Add 64-bit XIDs into PostgreSQL 15 - Mailing list pgsql-hackers

On 12/02/2026 08:17, Maxim Orlov wrote:
> 
> On Tue, 10 Feb 2026 at 17:54, Robert Haas <robertmhaas@gmail.com 
> <mailto:robertmhaas@gmail.com>> 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.

To repeat:

- It *will* increase the size of the database. That alone makes it a 
non-starter.

- Trying to make everything 64 bits in one patch makes the patch much 
harder to swallow. Too much to review and commit in one go.

> 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.

I don't oppose that. It would be a good thing. I would love to get 
there, assuming the storage size issue is solved, there are no other 
performance regressions etc. etc. But it won't happen in one patch.

We need to find ways to split this patch into smaller incremental parts, 
which can be reviewed and committed separately. That will move this 
forward. We got the 64-bit multixid offsets committed already. That 
alone was a big lift and took me quite a while to review and get into 
shape! Are there other parts like that that could be extracted and 
committed separately?

One idea is that we could first introduce the 33-bit epoch system on the 
heap pages, without changing the clog and without eliminating 
anti-wraparound vacuums. The immediate benefit would be that when you 
freeze a page, if there are no dead tuples, you wouldn't actually need 
to modify the page, and wouldn't need to dirty it. The rule would be 
that if you see an XID that's older than relfrozenxid (taking the epoch 
into account), you can assume that it committed and is visible to everyone.

After that, as a follow-up patch, expand clog to 64 bits and eliminate 
the need for anti-wraparound vacuums.

> 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.

The immediate benefit is that you never need to do anti-wraparound 
vacuums. The clog will grow indefinitely, so you'll need to vacuum 
eventually to truncate it to keep disk usage in check, but aside from 
running out of disk space, you will never get into the situation that 
your database just stops working because you didn't vacuum. That's a 
*huge* win!

- Heikki