Commit 558a9165e08 taught _bt_delitems_delete() to produce its own XID horizon on the primary. Standbys no longer needed to generate their own latestRemovedXid, since they could just use the explicitly logged value from the primary instead. The deleted offset numbers array from the xl_btree_delete WAL record was no longer used by the REDO routine for anything other than deleting the items.
This enables a minor optimization: We now treat the array as buffer state, not generic WAL data, following _bt_delitems_vacuum()'s example. This should be a minor win, since it allows us to avoid including the deleted items array in cases where XLogInsert() stores the whole buffer anyway. The primary goal here is to make the code more maintainable, though. Removing inessential differences between the two functions highlights the fundamental differences that remain.
Also change xl_btree_delete to use uint32 for the size of the array of item offsets being deleted. This brings xl_btree_delete closer to xl_btree_vacuum. Furthermore, it seems like a good idea to use an explicit-width integer type (the field was previously an "int").
Bump XLOG_PAGE_MAGIC because xl_btree_delete changed.
d2e5e20e57 Add xl_btree_delete optimization.
src/backend/access/nbtree/nbtpage.c | 48 +++++++++++++++--------------------
src/backend/access/nbtree/nbtxlog.c | 11 +++-----
src/backend/access/rmgrdesc/nbtdesc.c | 4 +--
src/include/access/nbtree.h | 3 ++-
src/include/access/nbtxlog.h | 6 ++---
src/include/access/xlog_internal.h | 2 +-
6 files changed, 32 insertions(+), 42 deletions(-)