On Wednesday, October 03, 2012 04:28:59 PM Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > Maybe I am missing something here, but reindex concurrently should do
> > 1) BEGIN
> > 2) Lock table in share update exlusive
> > 3) lock old index
> > 3) create new index
> > 4) obtain session locks on table, old index, new index
> > 5) commit
> > 6) process till newindex->insisready (no new locks)
> > 7) process till newindex->indisvalid (no new locks)
> > 8) process till !oldindex->indisvalid (no new locks)
> > 9) process till !oldindex->indisready (no new locks)
> > 10) drop all session locks
> > 11) lock old index exlusively which should be "invisible" now
> > 12) drop old index
> 
> You can't drop the session locks until you're done.  Consider somebody
> else trying to do a DROP TABLE between steps 10 and 11, for instance.
Yea, the session lock on the table itself probably shouldn't be dropped. If 
were holding only that one there shouldn't be any additional deadlock dangers 
when dropping the index due to lock upgrades as were doing the normal dance 
any DROP INDEX does. They seem pretty unlikely in a !valid !ready table 
anyway.

Greetings,

Andres
-- 
Andres Freund		http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

• Re: Support for REINDEX CONCURRENTLY at 2012-10-03 14:28:59 from Tom Lane

Responses

• Re: Support for REINDEX CONCURRENTLY at 2012-10-03 20:12:58 from Michael Paquier

pgsql-hackers by date

Next:	From: Amit Kapila	Date: 2012-10-03 15:15:16
	Subject: Re: Switching timeline over streaming replication
Previous:	From: Alvaro Herrera	Date: 2012-10-03 14:38:57
	Subject: Re: [9.1] 2 bugs with extensions