On 12/02/2026 08:17, Maxim Orlov wrote:
On Tue, 10 Feb 2026 at 17:54, Robert Haas <[email protected]
<mailto:[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.
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
