|
8 | 8 | * |
9 | 9 | * |
10 | 10 | * IDENTIFICATION |
11 | | - * $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.239 2004/08/31 17:10:36 tgl Exp $ |
| 11 | + * $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.240 2004/10/01 17:11:49 tgl Exp $ |
12 | 12 | * |
13 | 13 | * |
14 | 14 | * INTERFACE ROUTINES |
@@ -777,7 +777,7 @@ index_drop(Oid indexId) |
777 | 777 | * backend might be in the midst of devising a query plan that will |
778 | 778 | * use the index. The parser and planner take care to hold an |
779 | 779 | * appropriate lock on the parent table while working, but having them |
780 | | - * hold locks on all the indexes too seems overlycomplex.We do grab |
| 780 | + * hold locks on all the indexes too seems overlyexpensive.We do grab |
781 | 781 | * exclusive lock on the index too, just to be safe. Both locks must |
782 | 782 | * be held till end of transaction, else other backends will still see |
783 | 783 | * this index in pg_index. |
@@ -1655,26 +1655,19 @@ reindex_index(Oid indexId) |
1655 | 1655 | boolinplace; |
1656 | 1656 |
|
1657 | 1657 | /* |
1658 | | - * Open our index relation and get an exclusive lock on it. |
1659 | | - * |
1660 | | - * Note: for REINDEX INDEX, doing this before opening the parent heap |
1661 | | - * relation means there's a possibility for deadlock failure against |
1662 | | - * another xact that is doing normal accesses to the heap and index. |
1663 | | - * However, it's not real clear why you'd be wanting to do REINDEX |
1664 | | - * INDEX on a table that's in active use, so I'd rather have the |
1665 | | - * protection of making sure the index is locked down.In the REINDEX |
1666 | | - * TABLE and REINDEX DATABASE cases, there is no problem because |
1667 | | - * caller already holds exclusive lock on the parent table. |
| 1658 | + * Open and lock the parent heap relation. ShareLock is sufficient |
| 1659 | + * since we only need to be sure no schema or data changes are going on. |
| 1660 | + */ |
| 1661 | +heapId=IndexGetRelation(indexId); |
| 1662 | +heapRelation=heap_open(heapId,ShareLock); |
| 1663 | + |
| 1664 | +/* |
| 1665 | + * Open the target index relation and get an exclusive lock on it, |
| 1666 | + * to ensure that no one else is touching this particular index. |
1668 | 1667 | */ |
1669 | 1668 | iRel=index_open(indexId); |
1670 | 1669 | LockRelation(iRel,AccessExclusiveLock); |
1671 | 1670 |
|
1672 | | -/* Get OID of index's parent table */ |
1673 | | -heapId=iRel->rd_index->indrelid; |
1674 | | - |
1675 | | -/* Open and lock the parent heap relation */ |
1676 | | -heapRelation=heap_open(heapId,AccessExclusiveLock); |
1677 | | - |
1678 | 1671 | /* |
1679 | 1672 | * If it's a shared index, we must do inplace processing (because we |
1680 | 1673 | * have no way to update relfilenode in other databases). Otherwise |
@@ -1759,11 +1752,10 @@ reindex_relation(Oid relid, bool toast_too) |
1759 | 1752 | ListCell*indexId; |
1760 | 1753 |
|
1761 | 1754 | /* |
1762 | | - * Ensure to hold an exclusive lock throughout the transaction. The |
1763 | | - * lock could perhaps be less intensive (in the non-overwrite case) |
1764 | | - * but for now it's AccessExclusiveLock for simplicity. |
| 1755 | + * Open and lock the relation. ShareLock is sufficient since we only |
| 1756 | + * need to prevent schema and data changes in it. |
1765 | 1757 | */ |
1766 | | -rel=heap_open(relid,AccessExclusiveLock); |
| 1758 | +rel=heap_open(relid,ShareLock); |
1767 | 1759 |
|
1768 | 1760 | toast_relid=rel->rd_rel->reltoastrelid; |
1769 | 1761 |
|
|