Skip to content

Commit 1da9966

Browse files
committed
Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself."
This reverts commit a03e3e1 of 2011-04-15. There's a better way to do it, which will follow shortly.
1 parent b2e2d3a commit 1da9966

File tree

1 file changed

+4
-24
lines changed

1 file changed

+4
-24
lines changed

src/backend/catalog/index.c

Lines changed: 4 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1462,13 +1462,6 @@ index_build(Relation heapRelation,
14621462
HeapTuple indexTuple;
14631463
Form_pg_index indexForm;
14641464

1465-
/*
1466-
* Broken HOT chains should not get reported in system catalogs; in
1467-
* particular it would be quite dangerous to try to modify the index's
1468-
* pg_index entry if we are reindexing pg_index itself.
1469-
*/
1470-
Assert(!IsSystemRelation(heapRelation));
1471-
14721465
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
14731466

14741467
indexTuple = SearchSysCacheCopy1(INDEXRELID,
@@ -1528,13 +1521,7 @@ index_build(Relation heapRelation,
15281521
* A side effect is to set indexInfo->ii_BrokenHotChain to true if we detect
15291522
* any potentially broken HOT chains. Currently, we set this if there are
15301523
* any RECENTLY_DEAD entries in a HOT chain, without trying very hard to
1531-
* detect whether they're really incompatible with the chain tip. However,
1532-
* we do not ever set ii_BrokenHotChain true when the relation is a system
1533-
* catalog. This is to avoid problematic behavior when reindexing pg_index
1534-
* itself: we can't safely change the index's indcheckxmin field when we're
1535-
* partway through such an operation. It should be okay since the set of
1536-
* indexes on a system catalog ought not change during concurrent operations,
1537-
* so that no HOT chain in it could ever become broken.
1524+
* detect whether they're really incompatible with the chain tip.
15381525
*/
15391526
double
15401527
IndexBuildHeapScan(Relation heapRelation,
@@ -1711,8 +1698,7 @@ IndexBuildHeapScan(Relation heapRelation,
17111698
{
17121699
indexIt = false;
17131700
/* mark the index as unsafe for old snapshots */
1714-
if (!is_system_catalog)
1715-
indexInfo->ii_BrokenHotChain = true;
1701+
indexInfo->ii_BrokenHotChain = true;
17161702
}
17171703
else if (indexInfo->ii_BrokenHotChain)
17181704
indexIt = false;
@@ -1800,8 +1786,7 @@ IndexBuildHeapScan(Relation heapRelation,
18001786
{
18011787
indexIt = false;
18021788
/* mark the index as unsafe for old snapshots */
1803-
if (!is_system_catalog)
1804-
indexInfo->ii_BrokenHotChain = true;
1789+
indexInfo->ii_BrokenHotChain = true;
18051790
}
18061791
else if (indexInfo->ii_BrokenHotChain)
18071792
indexIt = false;
@@ -2496,13 +2481,8 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
24962481
* We can also reset indcheckxmin, because we have now done a
24972482
* non-concurrent index build, *except* in the case where index_build
24982483
* found some still-broken HOT chains.
2499-
*
2500-
* When reindexing a system catalog, don't do any of this --- it would be
2501-
* particularly risky to try to modify pg_index while we are reindexing
2502-
* pg_index itself. We don't support CREATE INDEX CONCURRENTLY on system
2503-
* catalogs anyway, and they should never have indcheckxmin set either.
25042484
*/
2505-
if (!skipped_constraint && !IsSystemRelation(heapRelation))
2485+
if (!skipped_constraint)
25062486
{
25072487
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
25082488

0 commit comments

Comments
 (0)