|
8 | 8 | * |
9 | 9 | * |
10 | 10 | * IDENTIFICATION |
11 | | - * $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.315 2009/03/3122:12:46 tgl Exp $ |
| 11 | + * $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.316 2009/05/3120:55:37 tgl Exp $ |
12 | 12 | * |
13 | 13 | * |
14 | 14 | * INTERFACE ROUTINES |
@@ -901,14 +901,13 @@ index_drop(Oid indexId) |
901 | 901 |
|
902 | 902 | /* |
903 | 903 | * To drop an index safely, we must grab exclusive lock on its parent |
904 | | - * table; otherwise there could be other backends using the index! |
905 | | - * Exclusive lock on the index alone is insufficient because another |
906 | | - * backend might be in the midst of devising a query plan that will use |
907 | | - * the index. The parser and planner take care to hold an appropriate |
908 | | - * lock on the parent table while working, but having them hold locks on |
909 | | - * all the indexes too seems overly expensive.We do grab exclusive lock |
910 | | - * on the index too, just to be safe. Both locks must be held till end of |
911 | | - * transaction, else other backends will still see this index in pg_index. |
| 904 | + * table. Exclusive lock on the index alone is insufficient because |
| 905 | + * another backend might be about to execute a query on the parent table. |
| 906 | + * If it relies on a previously cached list of index OIDs, then it could |
| 907 | + * attempt to access the just-dropped index. We must therefore take a |
| 908 | + * table lock strong enough to prevent all queries on the table from |
| 909 | + * proceeding until we commit and send out a shared-cache-inval notice |
| 910 | + * that will make them update their index lists. |
912 | 911 | */ |
913 | 912 | heapId=IndexGetRelation(indexId); |
914 | 913 | userHeapRelation=heap_open(heapId,AccessExclusiveLock); |
|