database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-05 09:19:17 +03:00
Code

Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself."

Browse Source 
This reverts commit 4b6106ccfea21e86943f881edcf3cfc03661a415 of 2011-04-15.
There's a better way to do it, which will follow shortly.
This commit is contained in:
Tom Lane 2011-04-19 16:55:34 -04:00
parent 385942f46c
commit c096d19b74
1 changed files with 4 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
src/backend/catalog/index.c
View File

@ -1770,13 +1770,6 @@ index_build(Relation heapRelation,
HeapTuple indexTuple; HeapTuple indexTuple;
Form_pg_index indexForm; 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); pg_index = heap_open(IndexRelationId, RowExclusiveLock);
indexTuple = SearchSysCacheCopy1(INDEXRELID, indexTuple = SearchSysCacheCopy1(INDEXRELID,
@ -1834,13 +1827,7 @@ index_build(Relation heapRelation,
* A side effect is to set indexInfo->ii_BrokenHotChain to true if we detect * 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 potentially broken HOT chains. Currently, we set this if there are
* any RECENTLY_DEAD entries in a HOT chain, without trying very hard to * any RECENTLY_DEAD entries in a HOT chain, without trying very hard to
* detect whether they're really incompatible with the chain tip. However, * detect whether they're really incompatible with the chain tip.
* 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.
*/ */
double double
IndexBuildHeapScan(Relation heapRelation, IndexBuildHeapScan(Relation heapRelation,
@ -2017,7 +2004,6 @@ IndexBuildHeapScan(Relation heapRelation,
{ {
indexIt = false; indexIt = false;
/* mark the index as unsafe for old snapshots */ /* 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) else if (indexInfo->ii_BrokenHotChain)
@ -2106,7 +2092,6 @@ IndexBuildHeapScan(Relation heapRelation,
{ {
indexIt = false; indexIt = false;
/* mark the index as unsafe for old snapshots */ /* 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) else if (indexInfo->ii_BrokenHotChain)
@ -2802,13 +2787,8 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
* We can also reset indcheckxmin, because we have now done a * We can also reset indcheckxmin, because we have now done a
* non-concurrent index build, *except* in the case where index_build * non-concurrent index build, *except* in the case where index_build
* found some still-broken HOT chains. * 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); pg_index = heap_open(IndexRelationId, RowExclusiveLock);