get rid of RM_HEAP2_ID
От | John Naylor |
---|---|
Тема | get rid of RM_HEAP2_ID |
Дата | |
Msg-id | CANWCAZaYQCD9+onVrhWXfhcS53tRJmL4Dr6tXa+pevruoBHqwg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: get rid of RM_HEAP2_ID
Re: get rid of RM_HEAP2_ID |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: