Re: get rid of RM_HEAP2_ID - Mailing list pgsql-hackers

From John Naylor
Subject Re: get rid of RM_HEAP2_ID
Date
Msg-id CANWCAZarSZxzuzWGL=V1H9sWBPVOS3++2qARbBh1Sh312VH+_A@mail.gmail.com
Whole thread Raw
In response to Re: get rid of RM_HEAP2_ID  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: get rid of RM_HEAP2_ID
List pgsql-hackers
On Tue, Oct 14, 2025 at 7:20 PM Heikki Linnakangas <hlinnaka@iki.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



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance
Next
From: Bertrand Drouvot
Date:
Subject: Re: Question about InvalidatePossiblyObsoleteSlot()