On Thu, May 26, 2011 at 11:52 AM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
