Re: Word-smithing doc changes - Mailing list pgsql-hackers

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 4DDB64CB.7070109@2ndQuadrant.com

I have simplified the concurrent index build docs with the attached
patch.

--
  Bruce Momjian  <bruce@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 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>