On Fri, 29 Dec 2023, 13:49 Maxim Orlov, <orlo...@gmail.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/
