mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-21 08:29:39 +08:00
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
This commit is contained in:
parent
2202891669
commit
a03feb9354
@ -381,7 +381,16 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ <replaceable class="parameter">name</
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If a problem arises while scanning the table, such as a
|
||||
uniqueness violation in a unique index, the <command>CREATE INDEX</>
|
||||
command will fail but leave behind an <quote>invalid</> index. This index
|
||||
|
Loading…
Reference in New Issue
Block a user