Skip to content

Commit c096d19

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

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
@@ -1770,13 +1770,6 @@ index_build(Relation heapRelation,
17701770
HeapTuple indexTuple;
17711771
Form_pg_index indexForm;
17721772

1773-
/*
1774-
* Broken HOT chains should not get reported in system catalogs; in
1775-
* particular it would be quite dangerous to try to modify the index's
1776-
* pg_index entry if we are reindexing pg_index itself.
1777-
*/
1778-
Assert(!IsSystemRelation(heapRelation));
1779-
17801773
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
17811774

17821775
indexTuple = SearchSysCacheCopy1(INDEXRELID,
@@ -1834,13 +1827,7 @@ index_build(Relation heapRelation,
18341827
* A side effect is to set indexInfo->ii_BrokenHotChain to true if we detect
18351828
* any potentially broken HOT chains. Currently, we set this if there are
18361829
* any RECENTLY_DEAD entries in a HOT chain, without trying very hard to
1837-
* detect whether they're really incompatible with the chain tip. However,
1838-
* we do not ever set ii_BrokenHotChain true when the relation is a system
1839-
* catalog. This is to avoid problematic behavior when reindexing pg_index
1840-
* itself: we can't safely change the index's indcheckxmin field when we're
1841-
* partway through such an operation. It should be okay since the set of
1842-
* indexes on a system catalog ought not change during concurrent operations,
1843-
* so that no HOT chain in it could ever become broken.
1830+
* detect whether they're really incompatible with the chain tip.
18441831
*/
18451832
double
18461833
IndexBuildHeapScan(Relation heapRelation,
@@ -2017,8 +2004,7 @@ IndexBuildHeapScan(Relation heapRelation,
20172004
{
20182005
indexIt = false;
20192006
/* mark the index as unsafe for old snapshots */
2020-
if (!is_system_catalog)
2021-
indexInfo->ii_BrokenHotChain = true;
2007+
indexInfo->ii_BrokenHotChain = true;
20222008
}
20232009
else if (indexInfo->ii_BrokenHotChain)
20242010
indexIt = false;
@@ -2106,8 +2092,7 @@ IndexBuildHeapScan(Relation heapRelation,
21062092
{
21072093
indexIt = false;
21082094
/* mark the index as unsafe for old snapshots */
2109-
if (!is_system_catalog)
2110-
indexInfo->ii_BrokenHotChain = true;
2095+
indexInfo->ii_BrokenHotChain = true;
21112096
}
21122097
else if (indexInfo->ii_BrokenHotChain)
21132098
indexIt = false;
@@ -2802,13 +2787,8 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
28022787
* We can also reset indcheckxmin, because we have now done a
28032788
* non-concurrent index build, *except* in the case where index_build
28042789
* found some still-broken HOT chains.
2805-
*
2806-
* When reindexing a system catalog, don't do any of this --- it would be
2807-
* particularly risky to try to modify pg_index while we are reindexing
2808-
* pg_index itself. We don't support CREATE INDEX CONCURRENTLY on system
2809-
* catalogs anyway, and they should never have indcheckxmin set either.
28102790
*/
2811-
if (!skipped_constraint && !IsSystemRelation(heapRelation))
2791+
if (!skipped_constraint)
28122792
{
28132793
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
28142794

0 commit comments

Comments
 (0)