postgres.git / summary / log / commit / refs

commit    c9c95202b036ea75dec68a4afc1802f35b77a966
Author:   Bruce Momjian <bruce@momjian.us>
Date:     Sat Aug 04 14:35:37 2012 +0000
First released in: 9.3.0, 9.1.5, 9.2.0

    Reword documentation for concurrent index rebuilds to be clearer.
    
    Backpatch to 9.1 and 9.2.


 doc/src/sgml/ref/create_index.sgml | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index 1a1e8d60d75..5d0ea4372fc 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -379,15 +379,14 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
    </para>
 
    <para>
-    In a concurrent index build, the index is actually entered into the
-    system catalogs in one transaction, then the two table scans occur in a
-    second and third transaction.  All active transactions at the time the
-    second table scan starts, not just ones that already involve the table,
-    have the potential to block the concurrent index creation until they
-    finish.  When checking for transactions that could still use the original
-    index, concurrent index creation advances through potentially interfering
-    older transactions one at a time, obtaining shared locks on their virtual
-    transaction identifiers to wait for them to complete.
+    In a concurrent index build, the index is actually entered into
+    the system catalogs in one transaction, then two table scans occur in
+    two more transactions.  Any transaction active when the second table
+    scan starts can block concurrent index creation until it completes,
+    even transactions that only reference the table after the second table
+    scan starts.   Concurrent index creation serially waits for each old
+    transaction to complete using the method outlined in section <xref
+    linkend="view-pg-locks">.
    </para>
 
    <para>


[parent: 805fc21c33f3]