Re: get rid of RM_HEAP2_ID

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: get rid of RM_HEAP2_ID
Date: 2025-10-15 04:51:35
Message-ID: CANWCAZarSZxzuzWGL=V1H9sWBPVOS3++2qARbBh1Sh312VH+_A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 14, 2025 at 7:20 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> This patch consumes one of the padding bytes. That's not entirely free,
> as there is an opportunity cost: we could squeeze out the padding bytes
> and save 2 bytes on every WAL record instead.

I must be misunderstanding, because I'm not sure how that would work
with the alignment requirement of later parts.

If you mean put some other parts of certain records into header (like
the xl_xact_info idea mentioned earlier, or something else), it's
worth thinking about that -- maybe some things would be helped by this
patch, and others would be closed off by it.

> I'd suggest some minor reordering and renaming:
>
> typedef struct XLogRecord
> {
> uint32 xl_tot_len; /* total len of entire record */
> TransactionId xl_xid; /* xact id */
> XLogRecPtr xl_prev; /* ptr to previous record in log */
> uint8 xl_flags; /* flag bits, see below */
> RmgrId xl_rmid; /* resource manager for this record */
> uint8 xl_rminfo; /* RMGR-specific info */
> /* 1 byte of padding here, initialize to zero */
> pg_crc32c xl_crc; /* CRC for this record */

Works for me.

> - Rename 'xl_info' to 'xl_rminfo' to make it more clear that it's
> RMGR-specific.

That makes sense here in the definition. There are also lots of local
variables named "info", and it would be less invasive to keep those as
they are. Likewise for the macro XLogRecGetInfo.

--
John Naylor
Amazon Web Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-10-15 04:51:38 Re: Question about InvalidatePossiblyObsoleteSlot()
Previous Message Ajin Cherian 2025-10-15 04:26:55 Re: Improve pg_sync_replication_slots() to wait for primary to advance