or use the index to terminate.  Thus
    this method requires more total work than a standard index build and takes
    significantly longer to complete.  However, since it allows normal
    operations to continue while the index is built, this method is useful for
    adding new indexes in a production environment.  Of course, the extra CPU
    and I/O load imposed by the index creation might slow other operations.
   </para>

   <para>
    In a concurrent index build, the index is actually entered as an
    <quote>invalid</quote> index into
    the system catalogs in one transaction, then two table scans occur in
    two more transactions.  Before each table scan, the index build must
    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, including transactions used by any phase of concurrent
    index builds on other tables, if the indexes involved are partial or have
    columns that are not simple column references.
    Then finally the index can be marked <quote>valid</quote> and 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
    predate the start of the index build.
   </para>

   <para>
    If a problem arises while scanning the table, such as a deadlock or a
    uniqueness violation in a unique index, the <command>CREATE INDEX</command>
    command will fail but leave behind an <quote>invalid</quote> index. This index
    will be ignored for querying purposes because it might be incomplete;
    however it will still consume update overhead. The <application>psql</application>
    <command>\d</command> command will report such an index as <literal>INVALID</literal>:

<programlisting>
postgres=# \d tab
       Table "public.tab"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 col    | integer |           |          |
Indexes:
    "idx" btree (col) INVALID
</programlisting>

    The recommended recovery
    method in such cases is to drop the index and try again to perform
    <command>CREATE INDEX CONCURRENTLY</command>.  (Another possibility is
    to rebuild the index with <command>REINDEX INDEX CONCURRENTLY</command>).
   </para>

   <para>
    Another caveat when building a unique index concurrently is that the
    uniqueness constraint is already being enforced against other transactions
    when the second table scan begins.  This means that constraint violations
    could be reported in other queries prior to the index becoming available
    for use, or even in cases where the index build eventually fails.  Also,
    if a failure does occur in the second scan, the <quote>invalid</quote> index
    continues to enforce its uniqueness constraint afterwards.
   </para>

   <para>
    Concurrent builds of expression indexes and partial indexes are supported.
    Errors occurring in the evaluation of these expressions could cause
    behavior similar to that described above for unique constraint violations.
   </para>

   <para>
    Regular index builds permit other regular index builds on the
    same table to occur simultaneously, but only one concurrent index build
    can occur on a table at a time.  In either case, schema modification of the
    table is not allowed while the index is being built.  Another difference is
    that a regular <command>CREATE INDEX</command> command can be performed
    within a transaction block, but <command>CREATE INDEX CONCURRENTLY</command>
    cannot.
   </para>

   <para>
    Concurrent builds for indexes on partitioned tables are currently not
    supported.  However, you may concurrently build the index on each
    partition individually and then finally