Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit4b6106c

Browse files
committed
Prevent incorrect updates of pg_index while reindexing pg_index itself.
The places that attempt to change pg_index.indcheckxmin during a reindexingoperation cannot be executed safely if pg_index itself is the subject ofthe operation. This is the explanation for a couple of recent reports ofVACUUM FULL failing withERROR: duplicate key value violates unique constraint "pg_index_indexrelid_index"DETAIL: Key (indexrelid)=(2678) already exists.However, there isn't any real need to update indcheckxmin in such asituation, if we assume that pg_index can never contain a truly broken HOTchain. This assumption holds if new indexes are never created on it duringconcurrent operations, which is something we don't consider safe for anysystem catalog, not just pg_index. Accordingly, modify the code to notmanipulate indcheckxmin when reindexing any system catalog.Back-patch to 8.3, where HOT was introduced. The known failure scenariosinvolve 9.0-style VACUUM FULL, so there might not be any real risk before9.0, but let's not assume that.
1 parentff5565f commit4b6106c

File tree

1 file changed

+24
-4
lines changed

1 file changed

+24
-4
lines changed

‎src/backend/catalog/index.c

Lines changed: 24 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1770,6 +1770,13 @@ index_build(Relation heapRelation,
17701770
HeapTupleindexTuple;
17711771
Form_pg_indexindexForm;
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+
17731780
pg_index=heap_open(IndexRelationId,RowExclusiveLock);
17741781

17751782
indexTuple=SearchSysCacheCopy1(INDEXRELID,
@@ -1827,7 +1834,13 @@ index_build(Relation heapRelation,
18271834
* A side effect is to set indexInfo->ii_BrokenHotChain to true if we detect
18281835
* any potentially broken HOT chains. Currently, we set this if there are
18291836
* any RECENTLY_DEAD entries in a HOT chain, without trying very hard to
1830-
* detect whether they're really incompatible with the chain tip.
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.
18311844
*/
18321845
double
18331846
IndexBuildHeapScan(RelationheapRelation,
@@ -2004,7 +2017,8 @@ IndexBuildHeapScan(Relation heapRelation,
20042017
{
20052018
indexIt= false;
20062019
/* mark the index as unsafe for old snapshots */
2007-
indexInfo->ii_BrokenHotChain= true;
2020+
if (!is_system_catalog)
2021+
indexInfo->ii_BrokenHotChain= true;
20082022
}
20092023
elseif (indexInfo->ii_BrokenHotChain)
20102024
indexIt= false;
@@ -2092,7 +2106,8 @@ IndexBuildHeapScan(Relation heapRelation,
20922106
{
20932107
indexIt= false;
20942108
/* mark the index as unsafe for old snapshots */
2095-
indexInfo->ii_BrokenHotChain= true;
2109+
if (!is_system_catalog)
2110+
indexInfo->ii_BrokenHotChain= true;
20962111
}
20972112
elseif (indexInfo->ii_BrokenHotChain)
20982113
indexIt= false;
@@ -2787,8 +2802,13 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
27872802
* We can also reset indcheckxmin, because we have now done a
27882803
* non-concurrent index build, *except* in the case where index_build
27892804
* 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.
27902810
*/
2791-
if (!skipped_constraint)
2811+
if (!skipped_constraint&& !IsSystemRelation(heapRelation))
27922812
{
27932813
pg_index=heap_open(IndexRelationId,RowExclusiveLock);
27942814

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp