From 1c15aac53f3421fd38ae145118d3204f055ba955 Mon Sep 17 00:00:00 2001
From: Kevin Grittner <kgrittn@postgresql.org>
Date: Tue, 19 Jul 2016 16:25:53 -0500
Subject: [PATCH] Add comment & docs about no vacuum truncation with sto.
Omission noted by Andres Freund.
---
doc/src/sgml/config.sgml | 9 +++++++++
src/backend/commands/vacuumlazy.c | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 4e8c982dd59..c9e0ec2c021 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2091,6 +2091,15 @@ include_dir 'conf.d'
transaction ID wraparound may occur in much shorter time frames.
</para>
+ <para>
+ When this feature is enabled, freed space at the end of a relation
+ cannot be released to the operating system, since that could remove
+ information needed to detect the <literal>snapshot too old</>
+ condition. All space allocated to a relation remains associated with
+ that relation for reuse only within that relation unless explicitly
+ freed (for example, with <command>VACUUM FULL</>).
+ </para>
+
<para>
This setting does not attempt to guarantee that an error will be
generated under any particular circumstances. In fact, if the
diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index 4075f4d1c92..231e92d8e46 100644
--- a/src/backend/commands/vacuumlazy.c
+++ b/src/backend/commands/vacuumlazy.c
@@ -1663,6 +1663,15 @@ lazy_cleanup_index(Relation indrel,
* Don't even think about it unless we have a shot at releasing a goodly
* number of pages. Otherwise, the time taken isn't worth it.
*
+ * Also don't attempt it if we are doing early pruning/vacuuming, because a
+ * scan which cannot find a truncated heap page cannot determine that the
+ * snapshot is too old to read that page. We might be able to get away with
+ * truncating all except one of the pages, setting its LSN to (at least) the
+ * maximum of the truncated range if we also treated an index leaf tuple
+ * pointing to a missing heap page as something to trigger the "snapshot too
+ * old" error, but that seems fragile and seems like it deserves its own patch
+ * if we consider it.
+ *
* This is split out so that we can test whether truncation is going to be
* called for before we actually do it. If you change the logic here, be
* careful to depend only on fields that lazy_scan_heap updates on-the-fly.
--
GitLab