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

Commitda5cf6a

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 parent77c616a commitda5cf6a

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
@@ -385,7 +385,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
385385
When this option is used,
386386
<productname>PostgreSQL</> must perform two scans of the table, and in
387387
addition it must wait for all existing transactions that could potentially
388-
use the index to terminate. Thus
388+
modify oruse the index to terminate. Thus
389389
this method requires more total work than a standard index build and takes
390390
significantly longer to complete. However, since it allows normal
391391
operations to continue while the index is built, this method is useful for
@@ -396,12 +396,15 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
396396
<para>
397397
In a concurrent index build, the index is actually entered into
398398
the system catalogs in one transaction, then two table scans occur in
399-
two more transactions. Any transaction active when the second table
400-
scan starts can block concurrent index creation until it completes,
401-
even transactions that only reference the table after the second table
402-
scan starts. Concurrent index creation serially waits for each old
403-
transaction to complete using the method outlined in section <xref
404-
linkend="view-pg-locks">.
399+
two more transactions. Before each table scan, the index build must
400+
wait for existing transactions that have modified the table to terminate.
401+
After the second scan, the index build must wait for any transactions
402+
that have a snapshot (see <xref linkend="mvcc">) predating the second
403+
scan to terminate. Then finally the index can be marked ready for use,
404+
and the <command>CREATE INDEX</> command terminates.
405+
Even then, however, the index may not be immediately usable for queries:
406+
in the worst case, it cannot be used as long as transactions exist that
407+
predate the start of the index build.
405408
</para>
406409

407410
<para>

0 commit comments

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