Skip to content

Commit a243c55

Browse files
committed
Cleanup comments in xlog compression
Skipping over the "hole" in full page images in the XLOG code was described as being a form of compression, but this got a bit confusing since we now have PGLZ-based compression happening, so adjust the wording to discuss "removing" the "hole" and keeping the talk about compression to where we're talking about using PGLZ-based compression of the full page images. Reviewed-By: Kyotaro Horiguchi Discussion: https://postgr.es/m/20181127234341.GM3415@tamriel.snowman.net
1 parent 228b048 commit a243c55

File tree

2 files changed

+8
-9
lines changed

2 files changed

+8
-9
lines changed

src/backend/access/transam/xloginsert.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -605,7 +605,7 @@ XLogRecordAssemble(RmgrId rmid, uint8 info,
605605
}
606606
else
607607
{
608-
/* No "hole" to compress out */
608+
/* No "hole" to remove */
609609
bimg.hole_offset = 0;
610610
cbimg.hole_length = 0;
611611
}

src/include/access/xlogrecord.h

+7-8
Original file line numberDiff line numberDiff line change
@@ -107,15 +107,14 @@ typedef struct XLogRecordBlockHeader
107107
* Additional header information when a full-page image is included
108108
* (i.e. when BKPBLOCK_HAS_IMAGE is set).
109109
*
110-
* As a trivial form of data compression, the XLOG code is aware that
111-
* PG data pages usually contain an unused "hole" in the middle, which
112-
* contains only zero bytes. If the length of "hole" > 0 then we have removed
113-
* such a "hole" from the stored data (and it's not counted in the
114-
* XLOG record's CRC, either). Hence, the amount of block data actually
115-
* present is BLCKSZ - the length of "hole" bytes.
110+
* The XLOG code is aware that PG data pages usually contain an unused "hole"
111+
* in the middle, which contains only zero bytes. Since we know that the
112+
* "hole" is all zeros, we remove it from the stored data (and it's not counted
113+
* in the XLOG record's CRC, either). Hence, the amount of block data actually
114+
* present is (BLCKSZ - <length of "hole" bytes>).
116115
*
117-
* When wal_compression is enabled, a full page image which "hole" was
118-
* removed is additionally compressed using PGLZ compression algorithm.
116+
* Additionally, when wal_compression is enabled, we will try to compress full
117+
* page images using the PGLZ compression algorithm, after removing the "hole".
119118
* This can reduce the WAL volume, but at some extra cost of CPU spent
120119
* on the compression during WAL logging. In this case, since the "hole"
121120
* length cannot be calculated by subtracting the number of page image bytes

0 commit comments

Comments
 (0)