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

On Fri, 29 Dec 2023, 13:49 Maxim Orlov, <orlovmg(at)gmail(dot)com> wrote:

> Hi!
>
> As were discussed in [0] our overall goal is to make Postgres 64 bit
> XIDs. It's obvious, that such a big patch set
> couldn't possible to commit "at once". SLUR patch set [1] was committed a
> short while ago as a first significant
> step in this direction.
>
> This thread is a next step in this enterprise. My objective here is to
> commit some changes, which were mandatory,
> as far as I understand, for any type of 64 XIDs implementation. And I'm
> sure there will be points for discussion here.
>
> My original intention was to make PGPROC->xmin, PGPROC->xid and
> PROC_HDR->xids 64bit. But in reality,
> it turned out to be much more difficult than I expected. On the one hand,
> the patch became too big and on the other
> hand, it's heavily relayed on epoch and XID "adjustment" to FXID. Therefore,
> for now, I decided to limit myself to
> more atomic and independent changes. However, as I said above, these
> changes are required for any implementation
> of 64bit XIDs.
>
> So, PFA patches to make switch PGPROC->xid
>

I think this could be fine, but ...

and XLogRecord->xl_xid to FullTransactionId.
>

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.

Kind regards

Matthias van de Meent

[0] https://commitfest.postgresql.org/46/4386/