I don't think this is an actionable change, as this wastes 4 more bytes (or 8 with alignment) in nearly all WAL records that don't use the HEAP/HEAP2/XLOG rmgrs, which would then be up to 10 (if not 14, when 64but-aligned) bytes per record. Unless something like [0] gets committed this will add a significant write overhead to all operations, even if they are not doing anything that needs an XID.
Also, I don't think we need to support transactions that stay alive and change things for longer than 2^31 concurrently created transactions, so we could well add a fxid to each WAL segment header (and checkpoint record?) and calculate the fxid of each record as a relative fxid off of that.
Thank you for your reply. Yes, this is a good idea. Actually, this is exactly what I was trying to do at first.
But in this case, we have to add more locks on TransamVariables->nextXid, and I've abandoned the idea.
Maybe, I should look in this direction.
And FWIW, echoing with Matthias, making these generic structures
arbitrary larger is a non-starter. We should try to make them
shorter.
Yeah, obviously, this is patch make WAL bigger. I'll try to look into the idea of fxid calculation, as mentioned above.
It might in part be a "chicken and the egg" situation. It is very hard to split overall 64xid patch into smaller pieces
with each part been a meaningful and beneficial for current 32xids Postgres.
Anyway, thanks for reply, appreciate it.
-- Best regards,
Maxim Orlov.