From 2cc41acd8fa3ebb8f0501c6102a253fb7053cf46 Mon Sep 17 00:00:00 2001 From: Kevin Grittner Date: Fri, 6 May 2016 07:47:12 -0500 Subject: Fix hash index vs "snapshot too old" problemms Hash indexes are not WAL-logged, and so do not maintain the LSN of index pages. Since the "snapshot too old" feature counts on detecting error conditions using the LSN of a table and all indexes on it, this makes it impossible to safely do early vacuuming on any table with a hash index, so add this to the tests for whether the xid used to vacuum a table can be adjusted based on old_snapshot_threshold. While at it, add a paragraph to the docs for old_snapshot_threshold which specifically mentions this and other aspects of the feature which may otherwise surprise users. Problem reported and patch reviewed by Amit Kapila --- doc/src/sgml/config.sgml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'doc/src') diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 94001241fc4..3d6baadaff2 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2077,6 +2077,19 @@ include_dir 'conf.d' allowed, please note that in many workloads extreme bloat or transaction ID wraparound may occur in much shorter time frames. + + + This setting does not attempt to guarantee that an error will be + generated under any particular circumstances. In fact, if the + correct results can be generated from (for example) a cursor which + has materialized a result set, no error will be generated even if the + underlying rows in the referenced table have been vacuumed away. + Some tables cannot safely be vacuumed early, and so will not be + affected by this setting. Examples include system catalogs and any + table which has a hash index. For such tables this setting will + neither reduce bloat nor create a possibility of a snapshot + too old error on scanning. + -- cgit v1.2.3