Document XLOG_INCLUDE_XID a little better

I noticed that commit 0bead9af48 left this flag undocumented in
XLogSetRecordFlags, which led me to discover that the flag doesn't
actually do what the one comment on it said it does.  Improve the
situation by adding some more comments.

Backpatch to 14, where the aforementioned commit appears.

Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/202109212119.c3nhfp64t2ql@alvherre.pgsql
This commit is contained in:
Alvaro Herrera 2021-09-21 19:47:53 -03:00
parent 43c1c4f65e
commit ade24dab97
No known key found for this signature in database
GPG Key ID: 1C20ACB9D5C564AE
3 changed files with 6 additions and 3 deletions

View File

@ -409,6 +409,8 @@ XLogRegisterBufData(uint8 block_id, char *data, int len)
* - XLOG_MARK_UNIMPORTANT, to signal that the record is not important for
* durability, which allows to avoid triggering WAL archiving and other
* background activity.
* - XLOG_INCLUDE_XID, a message-passing hack between XLogRecordAssemble
* and XLogResetInsertion.
*/
void
XLogSetRecordFlags(uint8 flags)

View File

@ -212,7 +212,7 @@ extern bool XLOG_DEBUG;
*/
#define XLOG_INCLUDE_ORIGIN 0x01 /* include the replication origin */
#define XLOG_MARK_UNIMPORTANT 0x02 /* record not important for durability */
#define XLOG_INCLUDE_XID 0x04 /* include XID of top-level xact */
#define XLOG_INCLUDE_XID 0x04 /* WAL-internal message-passing hack */
/* Checkpoint statistics */

View File

@ -215,8 +215,9 @@ typedef struct XLogRecordDataHeaderLong
* Block IDs used to distinguish different kinds of record fragments. Block
* references are numbered from 0 to XLR_MAX_BLOCK_ID. A rmgr is free to use
* any ID number in that range (although you should stick to small numbers,
* because the WAL machinery is optimized for that case). A couple of ID
* numbers are reserved to denote the "main" data portion of the record.
* because the WAL machinery is optimized for that case). A few ID
* numbers are reserved to denote the "main" data portion of the record,
* as well as replication-supporting transaction metadata.
*
* The maximum is currently set at 32, quite arbitrarily. Most records only
* need a handful of block references, but there are a few exceptions that