From 8ac700acffc7b17d88414be47b8dff44fb1ea681 Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Mon, 11 Apr 2022 09:49:13 +0900 Subject: [PATCH] doc: Clarify behavior of query planner locking with REINDEX MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The documentation of REINDEX has never mentioned that the query planner may take an ACCESS SHARE lock on the indexes depending on the query used. This adds also a note about prepared queries not impacted when they do not use the index(es) rebuilt. Author: Frédéric Yhuel Reviewed-by: Guillaume Lelarge, Justin Pryzby Discussion: https://postgr.es/m/65d08718-6f11-978a-4b5a-72b807d4c663@dalibo.com --- doc/src/sgml/ref/reindex.sgml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml index e6b25ee670..6a0eca8b9a 100644 --- a/doc/src/sgml/ref/reindex.sgml +++ b/doc/src/sgml/ref/reindex.sgml @@ -275,7 +275,12 @@ REINDEX [ ( option [, ...] ) ] { IN considerations are rather different. REINDEX locks out writes but not reads of the index's parent table. It also takes an ACCESS EXCLUSIVE lock on the specific index being processed, - which will block reads that attempt to use that index. In contrast, + which will block reads that attempt to use that index. In particular, + the query planner tries to take an ACCESS SHARE + lock on every index of the table, regardless of the query, and so + REINDEX blocks virtually any queries except for some + prepared queries whose plan has been cached and which don't use this very + index. In contrast, DROP INDEX momentarily takes an ACCESS EXCLUSIVE lock on the parent table, blocking both writes and reads. The subsequent CREATE INDEX locks out