diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index d800701ff4eec4a555280857991a28b73fdfd448..1234e7b33fec3cc69d3e8e00778bb7641b161d8f 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -385,7 +385,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
     When this option is used,
     <productname>PostgreSQL</> must perform two scans of the table, and in
     addition it must wait for all existing transactions that could potentially
-    use the index to terminate.  Thus
+    modify or use the index to terminate.  Thus
     this method requires more total work than a standard index build and takes
     significantly longer to complete.  However, since it allows normal
     operations to continue while the index is built, this method is useful for
@@ -396,12 +396,15 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
    <para>
     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">.
+    two more transactions.  Before each table scan, the index build must
+    wait for existing transactions that have modified the table to terminate.
+    After the second scan, the index build must wait for any transactions
+    that have a snapshot (see <xref linkend="mvcc">) predating the second
+    scan to terminate.  Then finally the index can be marked ready for use,
+    and the <command>CREATE INDEX</> command terminates.
+    Even then, however, the index may not be immediately usable for queries:
+    in the worst case, it cannot be used as long as transactions exist that
+    predate the start of the index build.
    </para>
 
    <para>