On Fri, Oct 10, 2025 at 9:47 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Oct 09, 2025 at 03:15:11PM +0700, John Naylor wrote:
> > Leaving that up to the rmgr makes sense. One consideration I didn't
> > mention was for xlogstats.c -- "record_stats[rmid][recid]" would get
> > 16x larger if recid could take up the full byte. Maybe that's
> > harmless, but I didn't want to assume. Any thoughts on that?
>
> I've missed this interaction, thanks for mentioning it. XLogStats is
> a local state that's only used by pg_walinspect and pg_waldump, so
> this extra memory consumed does worry me much; this stuff interacts
> with no critical paths.
Okay, v2 gets rid of the general info mask (split out into 0002 for
readability) and leaves alone the RMGR-specific masks (i.e. leaves out
v1 0002/3). It runs fine with installcheck while streaming to a
standby with wal_consistency_checking. I've also left out the removal
of HEAP2 for now. Giving existing RMGRs more breathing room seems like
a better motivator, going by Nathan's comment and yours.
It's worth thinking about backward compatibility if we did go as far
as a 2-byte xl_info (upthread: to allow more RMGR-specific flags, so
e.g. XACT wouldn't need xl_xact_info) In that case, we'd probably
still want a convention that only the lowest byte can contain the
record type. XLogStats could simply assume that in most cases. For
XACT 8 flags in the upper byte still won't be enough, and it will
still need to have its own opcode mask, but that's no worse than the
situation we have already.
--
John Naylor
Amazon Web Services
