From: Bruce Momjian Date: Sat, 4 Aug 2012 14:35:37 +0000 (-0400) Subject: Reword documentation for concurrent index rebuilds to be clearer. X-Git-Tag: REL9_3_BETA1~1140 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=4639432597d14f6cb29919eec3f9b4708d152b70;p=postgresql Reword documentation for concurrent index rebuilds to be clearer. Backpatch to 9.1 and 9.2. --- diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index 2ab6470367..17b433a47e 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -394,15 +394,14 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name - 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 .