Craig Ringer <craig@postnewspapers.com.au> 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
