Handle no-op visibility map set during redo add323da40a consolidated visibility map updates into XLOG_HEAP2_PRUNE records. It assumed that a record setting the visibility map would always modify the VM page during replay. That is not true when the requested bits are already set on the standby.
Primary and standby visibility maps can diverge for several reasons. This issue was exposed by a CREATE DATABASE ... STRATEGY WAL_LOG bug. After a standby with an out-of-date VM is promoted, VACUUM may set bits that were already present on the former primary. When the former primary later replays that record as a standby, visibilitymap_set() is a no-op. Restore visibilitymap_set()'s former API, which returns the state of the VM bits before setting the requested flags. Use that result to set the VM page LSN only when the visibilitymap_set() updates the page. Reported-by: Rogers Wang <[email protected]> Discussion: https://postgr.es/m/tencent_2E870046716FD94285045E96505A2D4E2908%40qq.com Backpatch-through: 19 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/3245795e13c4d9a6250da8276f7eaea27011f437 Modified Files -------------- src/backend/access/heap/heapam.c | 10 +++++----- src/backend/access/heap/heapam_xlog.c | 18 ++++++------------ src/backend/access/heap/pruneheap.c | 5 +++-- src/backend/access/heap/vacuumlazy.c | 16 ++++++++-------- src/backend/access/heap/visibilitymap.c | 6 +++++- src/include/access/visibilitymap.h | 6 +++--- 6 files changed, 30 insertions(+), 31 deletions(-)
