Re: Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid

On Fri, 29 Dec 2023 at 16:36, Matthias van de Meent <
boekewurm+postgres(at)gmail(dot)com> wrote:

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

On Sun, 31 Dec 2023 at 03:44, Michael Paquier <michael(at)paquier(dot)xyz> wrote:

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