On 09/02/2026 16:09, Maxim Orlov wrote:
Let me clear the situation with TransacionID and FullTransactionID
types. The patch is designed in a way to minimize the difference, as it
is already huge. Of course, after making TransacionID 64-bit, type
FullTransactionID lost it's meaning. We only need 32-bit type for
"on-disk" storage; everything else should be 64-bit.
AFAICS, the FullTransactionID type was added to minimize problems with
transaction counter wraparound in situations where it is not acceptable.
However, if we had 64-bit xids from the start, we wouldn't have needed
to do this. As a result, it is unclear to me why continuing to invest
in this type is important, despite the fact that it is not.
Maybe it's time to cut your losses and put them behind.
While I am not against utilizing the FullTransactionID type everywhere,
it will significantly complicate the patch by requiring all xids to be
transformed to FullTransactionID.
The point is that we still do not want to use FullTransactionID
everywhere. Only in some places related to visibility checks that need
to deal with XIDs stored on sidk, like heapam_visibility.c and clog.c,
and it will probably spill over to some other places. But things like
the proc array can continue to use 32-bit XIDs.
We will still have the limitation that you cannot have two transactions
*running* that are more than 2 billion XIDs apart. I think that's fine,
and we should not try to lift that limitation as part of this patch.
Let's try to minimize the scope and footprint of this patch.
=== OPT #1 - "real 64-bit XIDs" ===
After many years of working with this patch, I come to the conclusion
that the
best implementation option is to use full 64-bit transaction identifiers
in tuples.
And I do understand that this is an unpopular opinion.
But the truth is, this option was always rejected without further
investigation, as it automatically leads to increased disk space
consumption. Yes, the header of each tuple will become larger, but
if they have a meaningful size, the relative increase shouldn't be
significant.
Yeah no, I still think that's a non-starter, precisely because it will
further increase disk space consumption. And upgradability becomes even
more of a pain.
2) If not, what type of base should we use? 64 or 32 base?
33 bits base like Robert suggested seems best to me currently.
- Heikki
