From 1da9966230a30405ea5981403d4f4a9d83cb1ecb Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 19 Apr 2011 16:57:57 -0400 Subject: [PATCH] Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself." This reverts commit a03e3e1fd1d4ecfeb1096aeb7854b717061a75d9 of 2011-04-15. There's a better way to do it, which will follow shortly. --- src/backend/catalog/index.c | 28 ++++------------------------ 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c index 3dab69d98a..caa985a791 100644 --- a/src/backend/catalog/index.c +++ b/src/backend/catalog/index.c @@ -1462,13 +1462,6 @@ index_build(Relation heapRelation, HeapTuple indexTuple; Form_pg_index indexForm; - /* - * Broken HOT chains should not get reported in system catalogs; in - * particular it would be quite dangerous to try to modify the index's - * pg_index entry if we are reindexing pg_index itself. - */ - Assert(!IsSystemRelation(heapRelation)); - pg_index = heap_open(IndexRelationId, RowExclusiveLock); indexTuple = SearchSysCacheCopy1(INDEXRELID, @@ -1528,13 +1521,7 @@ index_build(Relation heapRelation, * A side effect is to set indexInfo->ii_BrokenHotChain to true if we detect * any potentially broken HOT chains. Currently, we set this if there are * any RECENTLY_DEAD entries in a HOT chain, without trying very hard to - * detect whether they're really incompatible with the chain tip. However, - * we do not ever set ii_BrokenHotChain true when the relation is a system - * catalog. This is to avoid problematic behavior when reindexing pg_index - * itself: we can't safely change the index's indcheckxmin field when we're - * partway through such an operation. It should be okay since the set of - * indexes on a system catalog ought not change during concurrent operations, - * so that no HOT chain in it could ever become broken. + * detect whether they're really incompatible with the chain tip. */ double IndexBuildHeapScan(Relation heapRelation, @@ -1711,8 +1698,7 @@ IndexBuildHeapScan(Relation heapRelation, { indexIt = false; /* mark the index as unsafe for old snapshots */ - if (!is_system_catalog) - indexInfo->ii_BrokenHotChain = true; + indexInfo->ii_BrokenHotChain = true; } else if (indexInfo->ii_BrokenHotChain) indexIt = false; @@ -1800,8 +1786,7 @@ IndexBuildHeapScan(Relation heapRelation, { indexIt = false; /* mark the index as unsafe for old snapshots */ - if (!is_system_catalog) - indexInfo->ii_BrokenHotChain = true; + indexInfo->ii_BrokenHotChain = true; } else if (indexInfo->ii_BrokenHotChain) indexIt = false; @@ -2496,13 +2481,8 @@ reindex_index(Oid indexId, bool skip_constraint_checks) * We can also reset indcheckxmin, because we have now done a * non-concurrent index build, *except* in the case where index_build * found some still-broken HOT chains. - * - * When reindexing a system catalog, don't do any of this --- it would be - * particularly risky to try to modify pg_index while we are reindexing - * pg_index itself. We don't support CREATE INDEX CONCURRENTLY on system - * catalogs anyway, and they should never have indcheckxmin set either. */ - if (!skipped_constraint && !IsSystemRelation(heapRelation)) + if (!skipped_constraint) { pg_index = heap_open(IndexRelationId, RowExclusiveLock); -- 2.40.0