Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commita65313f

Browse files
committed
Improve documentation about CREATE INDEX CONCURRENTLY.
Clarify the description of which transactions will block a CREATE INDEXCONCURRENTLY command from proceeding, and mention that the index mightstill not be usable after CREATE INDEX completes. (This happens if theindex build detected broken HOT chains, so that pg_index.indcheckxmin getsset, and there are open old transactions preventing the xmin horizon fromadvancing past the index's initial creation. I didn't want to explain whatbroken HOT chains are, though, so I omitted an explanation of exactly whenold transactions prevent the index from being used.)Per discussion with Chris Travers. Back-patch to all supported branches,since the same text appears in all of them.
1 parentab0757c commita65313f

File tree

1 file changed

+10
-7
lines changed

1 file changed

+10
-7
lines changed

‎doc/src/sgml/ref/create_index.sgml

Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -426,7 +426,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
426426
When this option is used,
427427
<productname>PostgreSQL</> must perform two scans of the table, and in
428428
addition it must wait for all existing transactions that could potentially
429-
use the index to terminate. Thus
429+
modify oruse the index to terminate. Thus
430430
this method requires more total work than a standard index build and takes
431431
significantly longer to complete. However, since it allows normal
432432
operations to continue while the index is built, this method is useful for
@@ -437,12 +437,15 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
437437
<para>
438438
In a concurrent index build, the index is actually entered into
439439
the system catalogs in one transaction, then two table scans occur in
440-
two more transactions. Any transaction active when the second table
441-
scan starts can block concurrent index creation until it completes,
442-
even transactions that only reference the table after the second table
443-
scan starts. Concurrent index creation serially waits for each old
444-
transaction to complete using the method outlined in section <xref
445-
linkend="view-pg-locks">.
440+
two more transactions. Before each table scan, the index build must
441+
wait for existing transactions that have modified the table to terminate.
442+
After the second scan, the index build must wait for any transactions
443+
that have a snapshot (see <xref linkend="mvcc">) predating the second
444+
scan to terminate. Then finally the index can be marked ready for use,
445+
and the <command>CREATE INDEX</> command terminates.
446+
Even then, however, the index may not be immediately usable for queries:
447+
in the worst case, it cannot be used as long as transactions exist that
448+
predate the start of the index build.
446449
</para>
447450

448451
<para>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp