From 173268f4d011fcae1f909c811e264baf6c838e7a Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Fri, 29 Mar 2019 22:47:33 +0100 Subject: [PATCH] doc: Small documentation review for REINDEX CONCURRENTLY Author: Justin Pryzby --- doc/src/sgml/ref/reindex.sgml | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml index e45bf86c8d..e05a76c6d8 100644 --- a/doc/src/sgml/ref/reindex.sgml +++ b/doc/src/sgml/ref/reindex.sgml @@ -300,11 +300,11 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR - A new temporary index definition is added into the catalog + A new temporary index definition is added to the catalog pg_index. This definition will be used to replace the old index. A SHARE UPDATE EXCLUSIVE lock at - session level is taken on the indexes being reindexed as well as its - associated table to prevent any schema modification while processing. + session level is taken on the indexes being reindexed as well as their + associated tables to prevent any schema modification while processing. @@ -312,7 +312,7 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR A first pass to build the index is done for each new index. Once the index is built, its flag pg_index.indisready is - switched to true to make ready for inserts, making it + switched to true to make it ready for inserts, making it visible to other sessions once the transaction that performed the build is finished. This step is done in a separate transaction for each index. @@ -322,7 +322,7 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR Then a second pass is performed to add tuples that were added while the - first pass build was running. This step is also done in a separate + first pass was running. This step is also done in a separate transaction for each index. @@ -331,10 +331,10 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR All the constraints that refer to the index are changed to refer to the new index definition, and the names of the indexes are changed. At - this point pg_index.indisvalid is switched to + this point, pg_index.indisvalid is switched to true for the new index and to false for - the old, and a cache invalidation is done so as all the sessions that - referenced the old index are invalidated. + the old, and a cache invalidation is done causing all sessions that + referenced the old index to be invalidated. @@ -359,8 +359,8 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR If a problem arises while rebuilding the indexes, such as a uniqueness violation in a unique index, the REINDEX - command will fail but leave behind an invalid new index on top - of the existing one. This index will be ignored for querying purposes + command will fail but leave behind an invalid new index in addition to + the pre-existing one. This index will be ignored for querying purposes because it might be incomplete; however it will still consume update overhead. The psql \d command will report such an index as INVALID: @@ -387,7 +387,7 @@ Indexes: Regular index builds permit other regular index builds on the same table - to occur in parallel, but only one concurrent index build can occur on a + to occur simultaneously, but only one concurrent index build can occur on a table at a time. In both cases, no other types of schema modification on the table are allowed meanwhile. Another difference is that a regular REINDEX TABLE or REINDEX INDEX @@ -406,7 +406,7 @@ Indexes: concurrently. If such an index is named directly in this command, an error is raised. If a table or database with exclusion constraint indexes is reindexed concurrently, those indexes will be skipped. (It is possible - to reindex such indexes without the concurrently option.) + to reindex such indexes without the CONCURRENTLY option.)