On Thu, May 26, 2011 at 11:52 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Greg Smith's message of mié may 25 17:04:03 -0400 2011:
>
>> Sure. Simon's command string idea might work better, and doing some
>> extra lock decoration as you suggested in the above thread would be
>> another level of improvement. We should pick up redesign later on the
>> main list. You can at least count me in as someone who wants to see
>> this improved now.
>
> Great
>
>> Back to the doc patch I submitted...is that a useful step toward making
>> this issue visible enough to users for now to help?
>
> Sure, why not? I thought I could choose my bikeshed color while I was
> here, how about
>
> + 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.
Alvaro, did you commit this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
