Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 3fe0e7c

Browse files
committed
Document concurrent indexes waiting on each other
Because regular CREATE INDEX commands are independent, and there's no logical data dependency, it's not immediately obvious that transactions held by concurrent index builds on one table will block the second phase of concurrent index creation on an unrelated table, so document this caveat. Backpatch this all the way back. In branch master, mention that only some indexes are involved. Author: James Coleman <jtc331@gmail.com> Reviewed-by: David Johnston <david.g.johnston@gmail.com> Discussion: https://postgr.es/m/CAAaqYe994=PUrn8CJZ4UEo_S-FfRr_3ogERyhtdgHAb2WG_Ufg@mail.gmail.com
1 parent d34916f commit 3fe0e7c

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

doc/src/sgml/ref/create_index.sgml

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -600,7 +600,8 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
600600
wait for existing transactions that have modified the table to terminate.
601601
After the second scan, the index build must wait for any transactions
602602
that have a snapshot (see <xref linkend="mvcc"/>) predating the second
603-
scan to terminate. Then finally the index can be marked ready for use,
603+
scan to terminate, including transactions used by any phase of concurrent
604+
index builds on other tables. Then finally the index can be marked ready for use,
604605
and the <command>CREATE INDEX</command> command terminates.
605606
Even then, however, the index may not be immediately usable for queries:
606607
in the worst case, it cannot be used as long as transactions exist that

0 commit comments

Comments
 (0)