On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> The concurrent index documentation under discussion above was never
> updated, so I took a stab at it, attached.
>
> Greg, I looked at adding a mention of the virtual transaction wait to
> the "explicit-locking" section as you suggested, and found those were
> all user-visible locking, while this is internal locking. I did find a
> clear description of transaction id locking in the pg_locks system view
> docs, so I just referenced that.
I found a way to clarify the wording further; patch attached.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
new file mode 100644
index 2ab6470..17b433a
*** a/doc/src/sgml/ref/create_index.sgml
--- b/doc/src/sgml/ref/create_index.sgml
*************** CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ]
*** 394,408 ****
</para>
<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. 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>
--- 394,407 ----
</para>
<para>
! In a concurrent index build, the index is actually entered into
! the system catalogs in one transaction, then two table scans occur in
! two more transactions. Any transaction active when the second table
! scan starts can block concurrent index creation until it completes,
! even transactions that only reference the table after the second table
! scan starts. Concurrent index creation serially waits for each old
! transaction to complete using the method outlined in section <xref
! linkend="view-pg-locks">.
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
