Alvaro Herrera wrote:
> Excerpts from Greg Stark's message of s??b jun 25 21:01:36 -0400 2011:
> > I think this commit was ill-advised:
> > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
>
> > Seems way to implementation-specific and detailed for a user to make
> > heads or tails of. Except in the sections talking about locking
> > internals we don't talk about "shared locks on virtual transactions
> > identifiers" we just talk about waiting for a transaction to complete.
>
> Hmm, right.
>
> > And looping over the transactions one by one is purely an
> > implementation detail and uninteresting to users. Also it uses
> > ill-defined terms like "active transactions", "potentially interfering
> > older transactions", and "original index" -- from the user's point of
> > view there's only one index and it just isn't completely built yet.
>
> Wow, that's a lot of mistakes for a single paragraph, sorry about that.
>
> > Are we not yet in string-freeze though? I'll go ahead and edit it if
> > people don't mind. I'm curious to see the original complaint though.
>
> I don't -- please go ahead.
>
> Original complaint in Message-id [email protected]
I have simplified the concurrent index build docs with the attached
patch.
--
Bruce Momjian <[email protected]> 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 e8a7caf..7391a5f
*** a/doc/src/sgml/ref/create_index.sgml
--- b/doc/src/sgml/ref/create_index.sgml
*************** CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ]
*** 400,413 ****
<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>
--- 400,409 ----
<para>
In a concurrent index build, the index is actually entered into the
! system catalogs in one transaction; two table scans then occur in a
! second and third transaction. The concurrent index build will not
! complete until all running transactions can see the new index
! definition.
</para>
<para>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
