database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-27 22:56:53 +03:00
Code

doc: Clarify behavior of query planner locking with REINDEX

Browse Source 
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
This commit is contained in:
Michael Paquier 2022-04-11 09:49:13 +09:00
parent cd959b1b06
commit 8ac700acff
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/src/sgml/ref/reindex.sgml
View File

@ -275,7 +275,12 @@ REINDEX [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] { IN
considerations are rather different. <command>REINDEX</command> locks out writes
but not reads of the index's parent table. It also takes an
<literal>ACCESS EXCLUSIVE</literal> 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 <literal>ACCESS SHARE</literal>
lock on every index of the table, regardless of the query, and so
<command>REINDEX</command> blocks virtually any queries except for some
prepared queries whose plan has been cached and which don't use this very
index. In contrast,
<command>DROP INDEX</command> momentarily takes an
<literal>ACCESS EXCLUSIVE</literal> lock on the parent table, blocking both
writes and reads. The subsequent <command>CREATE INDEX</command> locks out