From: Justin Pryzby <pryzby@telsasoft.com>
To: Bossart, Nathan <bossartn@amazon.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Treat <rob@xzilla.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Sergei Kornilov <sk@zsrv.org>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: REINDEX CONCURRENTLY 2.0
Date: Fri, 29 Mar 2019 11:01:23 -0500
Message-ID: <20190329160122.GJ5815@telsasoft.com> (raw)
In-Reply-To: <55DE37D6-984F-4EFE-9D5E-521906D8F032@amazon.com>
References: <154954968565.11785.6973123402105637191.pgcf@coridan.postgresql.org>
<1730471552486423@myt1-cd60b8ae9bb9.qloud-c.yandex.net>
<3b33640c-5493-4eea-fd5f-71d37626fe2f@2ndquadrant.com>
<1907751553367887@myt6-23299ba78d64.qloud-c.yandex.net>
<64744529-d34e-9aae-e7e3-e2263c24fb3b@2ndquadrant.com>
<7380711553760479@iva5-0acfc31d2b43.qloud-c.yandex.net>
<13fb3e06-3b66-e878-26d8-0d77e7d50160@2ndquadrant.com>
<CABV9wwMQS6CoS5OrTfZFZJX53jOJNHP35y9MeuBeKF-++LbpYg@mail.gmail.com>
<20190329154803.gfb4rvmflbniheh3@alap3.anarazel.de>
<55DE37D6-984F-4EFE-9D5E-521906D8F032@amazon.com>
On Fri, Mar 29, 2019 at 03:53:05PM +0000, Bossart, Nathan wrote:
> I noticed a very small typo in the documentation for this feature.
I submit a bunch more changes for consideration, attached.
Attachments:
[text/x-diff] v1-0001-Doc-review-for-REINDEX-CONCURRENTLY.patch (5.1K, ../20190329160122.GJ5815@telsasoft.com/2-v1-0001-Doc-review-for-REINDEX-CONCURRENTLY.patch)
download | inline diff:
From dafdb15fb3e7c69de82a2206c9bf07588b5665ce Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Fri, 29 Mar 2019 10:59:59 -0500
Subject: [PATCH v1] Doc review for REINDEX CONCURRENTLY
---
doc/src/sgml/ref/reindex.sgml | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgmlindex ccabb33..e05a76c 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
<orderedlist>
<listitem>
<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
the old index. A <literal>SHARE UPDATE EXCLUSIVE</literal> 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.
</para>
</listitem>
@@ -312,7 +312,7 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<para>
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
- 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
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
<listitem>
<para>
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.
</para>
</listitem>
@@ -331,10 +331,10 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<para>
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 <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
- 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.
</para>
</listitem>
@@ -349,7 +349,7 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<listitem>
<para>
The old indexes are dropped. The <literal>SHARE UPDATE
- EXCLUSIVE</literal> session locks for the indexes and the table ar+ EXCLUSIVE</literal> session locks for the indexes and the table are
released.
</para>
</listitem>
@@ -359,8 +359,8 @@ REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURR
<para>
If a problem arises while rebuilding the indexes, such as a
uniqueness violation in a unique index, the <command>REINDEX</command>
- command will fail but leave behind an <quote>invalid</quote> new index on top- of the existing one. This index will be ignored for querying purposes+ command will fail but leave behind an <quote>invalid</quote> 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 <application>psql</application> <command>\d</command> command will report
such an index as <literal>INVALID</literal>:
@@ -387,7 +387,7 @@ Indexes:
<para>
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
<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
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 <command>CONCURRENTLY</command> option.)
</para>
</refsect2>
</refsect1>
--
2.1.4
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, bossartn@amazon.com, andres@anarazel.de, rob@xzilla.net, peter.eisentraut@2ndquadrant.com, sk@zsrv.org, pgsql-hackers@lists.postgresql.org
Subject: Re: REINDEX CONCURRENTLY 2.0
In-Reply-To: <20190329160122.GJ5815@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox