From 5698f07947396e1a7cd6564390306aafa26fc189 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Mon, 8 May 2023 13:17:31 -0700 Subject: Doc: update VACUUM FREEZE query conflict guidance. Commit 1de58df4, which added page-level freezing, taught VACUUM to reuse each page's "set-visibility-map" snapshotConflictHorizon for freezing (at least in the vast majority of cases where freezing went ahead). This made VACUUM FREEZE much less prone to generating recovery conflicts on standbys; VACUUM FREEZE became only slightly more likely to cause recovery conflicts than an equivalent VACUUM. Update old documentation that specifically warned of the likelihood of recovery conflicts from VACUUM FREEZE. Explain the same general issue (the issue of VACUUM generating recovery conflicts even in the absence of dead row cleanup) using the example of conflicts caused by VISIBLE WAL records. --- doc/src/sgml/high-availability.sgml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index cf61b2ed2a..5f9257313a 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1873,10 +1873,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' - Experienced users should note that both row version cleanup and row version - freezing will potentially conflict with standby queries. Running a manual - VACUUM FREEZE is likely to cause conflicts even on tables with - no updated or deleted rows. + Row version cleanup isn't the only potential cause of conflicts with + standby queries. All index-only scans (including those that run on + standbys) must use an MVCC snapshot that + agrees with the visibility map. Conflicts are therefore + required whenever VACUUM sets a page as all-visible in the + visibility map containing one or more rows + not visible to all standby queries. So even running + VACUUM against a table with no updated or deleted rows + requiring cleanup might lead to conflicts. -- cgit v1.2.1