Re: Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid
От | Matthias van de Meent |
---|---|
Тема | Re: Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid |
Дата | |
Msg-id | CAEze2WhB_y7tVNTSObn9o-=SP+ohZ8JUDTKzs=ZBON+egmp5mg@mail.gmail.com обсуждение исходный текст |
Ответ на | Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid (Maxim Orlov <orlovmg@gmail.com>) |
Ответы |
Re: Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid
|
Список | pgsql-hackers |
On Fri, 29 Dec 2023, 13:49 Maxim Orlov, <orlovmg@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 setcouldn't possible to commit "at once". SLUR patch set [1] was committed a short while ago as a first significantstep 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 otherhand, it's heavily relayed on epoch and XID "adjustment" to FXID. Therefore, for now, I decided to limit myself tomore atomic and independent changes. However, as I said above, these changes are required for any implementationof 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
В списке pgsql-hackers по дате отправления: