On Thu, Oct 9, 2025 at 1:43 PM Michael Paquier <michael@paquier.xyz> wrote:
> > 0001: Split xl_info into xl_info for rmgr-specific info and xl_geninfo
> > for generic flags. I used the XLogInsertExtended() idea from one of
> > Matthias's patches in [3], but wrote the rest a different way to keep
> > churn small.
>
> Removing XLR_RMGR_INFO_MASK becomes natural here, causing
> XLR_INFO_MASK to also become unnecessary. One benefit of this
> proposal is that we would not need a heap3 once the opcodes are
> completely full for the two existing ones, which should be fine enough
> for many years to come. I have noticed after writing this sentence
> that it is what Matthias has done in his patch to separate these
> fields. More code churn, but I'd be in favor of fully biting the
> bullet and do as Matthias is proposing, getting rid of XLR_INFO_MASK
> entirely if we let the full byte at disposal of the RMGRs.
Okay.
> > 0002 and 0003: To simplify the rmgrs that have an opmask and separate
> > flag (I saw two obvious ones but I didn't make sure they were the only
> > ones), reserve the high 4 bits of xl_info for the "record type" (I see
> > xlogstats.c calls it a "recid", so that might be a better name) and
> > the lower 4 bits for the flag. Using the same scheme everywhere
> > simplifies things.
>
> XLR_REC_TYPE_MASK and XLR_REC_FLAGS_MASK seem a bit confusing to me.
> This is an attempt to generalize a rule that two RMGRs have been using
> locally. In short I am not sure what we are gaining here, coming back
> to the previous point that we should get rid of XLR_INFO_MASK, IMO.
> That's the kind of rules I'd leave up to the RMGRs, so this does not
> like a necessary abstraction, at least IMO.
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?
--
John Naylor
Amazon Web Services
