From 9adda3e125642f41f256d1ed6adfe810b508e046 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Mon, 13 Jun 2011 17:12:26 -0400 Subject: [PATCH] Expand warnings on locks acquired by CREATE INDEX CONCURRENTLY The previous wording wasn't explicit enough, which could misled readers into thinking that the locks acquired are more restricted in nature than they really are. The resulting optimism can be damaging to morale when confronted with reality, as has been observed in the field. Greg Smith --- doc/src/sgml/ref/create_index.sgml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index 43b6499603..f7f360875c 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -381,7 +381,16 @@ 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. + 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. + + + If a problem arises while scanning the table, such as a uniqueness violation in a unique index, the CREATE INDEX command will fail but leave behind an invalid index. This index -- 2.40.0