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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Maxim Orlov <orlovmg(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid
Date: 2023-12-31 00:44:32
Message-ID: ZZC5cJTKgYcdWOvz@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 29, 2023 at 02:36:19PM +0100, Matthias van de Meent 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.

I was eyeing at the patches before reading your comment, and saw this
across the two patches:

@@ -176,7 +176,7 @@ struct PGPROC
Latch procLatch; /* generic latch for process */


- TransactionId xid; /* id of top-level transaction currently being
+ FullTransactionId xid; /* id of top-level transaction currently being
[...]
typedef struct XLogRecord
{
uint32 xl_tot_len; /* total len of entire record */
- TransactionId xl_xid; /* xact id */
+ pg_crc32c xl_crc; /* CRC for this record */
+ FullTransactionId xl_xid; /* xact id */

And FWIW, echoing with Matthias, making these generic structures
arbitrary larger is a non-starter. We should try to make them
shorter.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-12-31 00:49:13 Re: Commitfest 2024-01 starting in 3 days!
Previous Message Michael Paquier 2023-12-31 00:37:31 Re: Add PQsendSyncMessage() to libpq