pgsql: Handle no-op visibility map set during redo

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 <rogers(dot)ww(at)qq(dot)com>
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(-)