From 4639432597d14f6cb29919eec3f9b4708d152b70 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sat, 4 Aug 2012 10:35:37 -0400 Subject: [PATCH] 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 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 . -- 2.40.0