Just for background. The showstopper for REINDEX concurrently was not that it was particularly hard to actually do the reindexing. But it's not obvious how to obtain a lock on both the old and new index without creating a deadlock risk. I don't remember exactly where the deadlock risk lies but there are two indexes to lock and whichever order you obtain the locks it might be possible for someone else to be waiting to obtain them in the opposite order.
I'm sure it's possible to solve the problem. But the footwork needed to release locks then reobtain them in the right order and verify that the index hasn't changed out from under you might be a lot of headache. Perhaps a good way to tackle it is to have a generic "verify two indexes are equivalent and swap the underlying relfilenodes" operation that can be called from both regular reindex and reindex concurrently. As long as it's the only function that ever locks two indexes then it can just determine what locking discipline it wants to use. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers