Neil Conway wrote: > On Fri, 2007-18-05 at 11:47 -0500, Jim C. Nasby wrote: > > Assuming the concurrent psql stuff gets in, do you still see a use for > > this? > > I think concurrent psql (and/or async libpq) is the right way to handle > this sort of requirement. "DROP INDEX NOWAIT" is hacky, and would be > difficult (impossible?) to implement in a reasonable manner: the backend > is fundamentally single-threaded. Also, how does the client learn when > the DROP INDEX actually finishes? The client would either need to poll > the database, or we'd need to implement something like select() -- > neither is a very appealing alternative.
I think what Joshua really wants is an equivalent of this: start: BEGIN; LOCK TABLE foo IN ACCESS EXCLUSIVE MODE NOWAIT; -- if fail, rollback and go to start DROP INDEX foo_idx; COMMIT; The idea is that the lock is only acquired if immediately available, thus not blocking other queries which would otherwise be blocked behind the DROP INDEX. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match