mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Document concurrent indexes waiting on each other

Browse Source 
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
This commit is contained in:
Alvaro Herrera 2020-11-30 18:24:55 -03:00
parent d34916fee5
commit 3fe0e7c3fa
No known key found for this signature in database
GPG Key ID: 1C20ACB9D5C564AE
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/src/sgml/ref/create_index.sgml
View File

@ -600,7 +600,8 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
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,
scan to terminate, including transactions used by any phase of concurrent
index builds on other tables. Then finally the index can be marked ready for use,
and the <command>CREATE INDEX</command> 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