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 ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d69b06e5abea6db7151daf764e1069c7bc7f60ac 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(-)
