Making the XLogRecord header nicer has been proposed several times
[1][2][3]. In [2], Robert wondered if with 2 bytes of xl_info, we
could get rid of the separate xl_xact_info. There could be other
possibilities as well, but I haven't done anything in that direction.
The attached just gets as far as the modest goal mentioned in the
subject.
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.
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.
I've put the mask into these macros to reduce the places that know about them:
#define XLogRecGetRecType(decoder) ((decoder)->record->header.xl_info
& XLR_REC_TYPE_MASK)
#define XLogRecGetRecFlags(decoder) ((decoder)->record->header.xl_info
& XLR_REC_FLAGS_MASK)
The former is for callers that explicitly want to know about the
record type only, without flags. The latter is unused, since checking
a mask doesn't need to isolate all the masks first, so it may not end
up in the final version.
There are new XLR_* masks whose names reflect their new purpose
better, but they are the same values as the old ones. XLR_INFO_MASK is
kept around for compatibility, but it doesn't do anything useful since
the rmgr has the full byte available. In order for ~XLR_INFO_MASK to
become a no-op on a full byte, XLR_INFO_MASK has to be zero, which
looks very odd. Removing it would be clearer, at the cost of more
churn.
There is a small wrinkle in that heap_identify does different things
depending on presence of the XLOG_HEAP_INIT_PAGE flag, but
xact_identify() doesn't do that with XLOG_XACT_HAS_INFO, so the latter
still masks out the flags.
0004: get rid of RM_HEAP2_ID. This was simple once the prerequisites
were in place. All of the HEAP2_* macros keep the same name and only
differ in value. Heap rmgr is completely full so it might be good to
increase to 5 bits for the record type to give it some breathing room.
I wasn't sure about this comment in heapam_xlog.c -- it seems strange
that this property would occur exactly at the point where the first
heap rmgr id ran out of bits, but check world passes without doing
anything additional:
/*
* These operations don't overwrite MVCC data so no conflict processing is
* required. The ones in heap2 rmgr do.
*/
[1] https://www.postgresql.org/message-id/20220715173731.6t3km5cww3f5ztfq%40awork3.anarazel.de
[2] https://www.postgresql.org/message-id/CA%2BTgmoa7pNxxe_K%3D3mTHHZGSmnrc_YgApArx3OFHN2g57nzLNw%40mail.gmail.com
[3] https://www.postgresql.org/message-id/CAEze2Wjd3jY_UhhOGdGGnC6NO%3D%2BNmtNOmd%3DJaYv-v-nwBAiXXA%40mail.gmail.com
--
John Naylor
Amazon Web Services
