Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> writes: > The locking docs: > http://www.postgresql.org/docs/8.3/static/explicit-locking.html > don't say anything about which lock DROP INDEX takes on a relation. A > quick test shows it takes an AccessExclusiveLock on the affected index, > and appears to take no lock at all on the table: Not sure how you tested that, but index_drop() clearly takes AccessExclusiveLock on the table too. (I'm not sure it really needs to --- the comment therein defending the reasoning seems out of date --- but it definitely does.) Whether it did lock the table or not, though, the index lock would certainly interfere with queries trying to use that index, or even just considering using the index during planning. So the recommended method (CREATE new index, DROP old, RENAME) is designed to hold lock on the old index for as short a time as possible. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
