Mention REINDEX CONCURRENTLY in documentation about index maintenance

The documentation includes a section about index maintenance and
reindexing, mentioning a set of steps based on CREATE INDEX CONCURRENTLY
and ALTER TABLE (for constraint dependencies) to emulate REINDEX
CONCURRENTLY.  Now that REINDEX CONCURRENTLY is supported, let's just
directly mention it instead.

Reported-by: Peter Geoghegan
Author: Michael Paquier
Reviewed-by: Peter Eisentraut, Tom Lane
Discussion: https://postgr.es/m/CAH2-WzmEL168t6w29aKrKXtpq9-apcmp0HC7K-fKt6ZgLXV6Dg@mail.gmail.com

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 1c4fc40489e62dc175ccdaef23bb39ee0fb3ea47..1972c20a8fd0e3a96f5bf905e2aa717b234b3ef7 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -869,19 +869,10 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
 
   
     can be used safely and easily in all cases.
-   But since the command requires an exclusive table lock, it is
-   often preferable to execute an index rebuild with a sequence of
-   creation and replacement steps.  Index types that support
-    with the CONCURRENTLY
-   option can instead be recreated that way. If that is successful and the
-   resulting index is valid, the original index can then be replaced by
-   the newly built one using a combination of 
-   and . When an index is used to enforce
-   uniqueness or other constraints,  might
-   be necessary to swap the existing constraint with one enforced by
-   the new index. Review this alternate multistep rebuild approach
-   carefully before using it as there are limitations on which
-   indexes can be reindexed this way, and errors must be handled.
+   This command requires an ACCESS EXCLUSIVE lock by
+   default, hence it is often preferable to execute it with its
+   CONCURRENTLY option which requires only a
+   SHARE UPDATE EXCLUSIVE lock.