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  (Michael Paquier <michael@paquier.xyz>)
Список 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 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Fix Brin Private Spool Initialization (src/backend/access/brin/brin.c)
Следующее
От: Ranier Vilela
Дата:
Сообщение: Re: Fix Brin Private Spool Initialization (src/backend/access/brin/brin.c)