doc: Small documentation review for REINDEX CONCURRENTLY

Author: Justin Pryzby <pryzbyj@telsasoft.com>
This commit is contained in:
Peter Eisentraut 2019-03-29 22:47:33 +01:00
parent 0267629e18
commit 173268f4d0

View File

@ -300,11 +300,11 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<orderedlist> <orderedlist>
<listitem> <listitem>
<para> <para>
A new temporary index definition is added into the catalog A new temporary index definition is added to the catalog
<literal>pg_index</literal>. This definition will be used to replace <literal>pg_index</literal>. This definition will be used to replace
the old index. A <literal>SHARE UPDATE EXCLUSIVE</literal> lock at the old index. A <literal>SHARE UPDATE EXCLUSIVE</literal> lock at
session level is taken on the indexes being reindexed as well as its session level is taken on the indexes being reindexed as well as their
associated table to prevent any schema modification while processing. associated tables to prevent any schema modification while processing.
</para> </para>
</listitem> </listitem>
@ -312,7 +312,7 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<para> <para>
A first pass to build the index is done for each new index. Once the A first pass to build the index is done for each new index. Once the
index is built, its flag <literal>pg_index.indisready</literal> is index is built, its flag <literal>pg_index.indisready</literal> is
switched to <quote>true</quote> to make ready for inserts, making it switched to <quote>true</quote> to make it ready for inserts, making it
visible to other sessions once the transaction that performed the build visible to other sessions once the transaction that performed the build
is finished. This step is done in a separate transaction for each is finished. This step is done in a separate transaction for each
index. index.
@ -322,7 +322,7 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<listitem> <listitem>
<para> <para>
Then a second pass is performed to add tuples that were added while the 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. transaction for each index.
</para> </para>
</listitem> </listitem>
@ -331,10 +331,10 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<para> <para>
All the constraints that refer to the index are changed to refer to the 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 new index definition, and the names of the indexes are changed. At
this point <literal>pg_index.indisvalid</literal> is switched to this point, <literal>pg_index.indisvalid</literal> is switched to
<quote>true</quote> for the new index and to <quote>false</quote> for <quote>true</quote> for the new index and to <quote>false</quote> for
the old, and a cache invalidation is done so as all the sessions that the old, and a cache invalidation is done causing all sessions that
referenced the old index are invalidated. referenced the old index to be invalidated.
</para> </para>
</listitem> </listitem>
@ -359,8 +359,8 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<para> <para>
If a problem arises while rebuilding the indexes, such as a If a problem arises while rebuilding the indexes, such as a
uniqueness violation in a unique index, the <command>REINDEX</command> uniqueness violation in a unique index, the <command>REINDEX</command>
command will fail but leave behind an <quote>invalid</quote> new index on top command will fail but leave behind an <quote>invalid</quote> new index in addition to
of the existing one. This index will be ignored for querying purposes the pre-existing one. This index will be ignored for querying purposes
because it might be incomplete; however it will still consume update because it might be incomplete; however it will still consume update
overhead. The <application>psql</application> <command>\d</command> command will report overhead. The <application>psql</application> <command>\d</command> command will report
such an index as <literal>INVALID</literal>: such an index as <literal>INVALID</literal>:
@ -387,7 +387,7 @@ Indexes:
<para> <para>
Regular index builds permit other regular index builds on the same table 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 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 the table are allowed meanwhile. Another difference is that a regular
<command>REINDEX TABLE</command> or <command>REINDEX INDEX</command> <command>REINDEX TABLE</command> or <command>REINDEX INDEX</command>
@ -406,7 +406,7 @@ Indexes:
concurrently. If such an index is named directly in this command, an concurrently. If such an index is named directly in this command, an
error is raised. If a table or database with exclusion constraint indexes error is raised. If a table or database with exclusion constraint indexes
is reindexed concurrently, those indexes will be skipped. (It is possible 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 <command>CONCURRENTLY</command> option.)
</para> </para>
</refsect2> </refsect2>
</refsect1> </refsect1>