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

Commit32c893c

Browse files
committed
Avoid returning stale attribute bitmaps in RelationGetIndexAttrBitmap().
The problem with the original coding here is that we might receive (andclear) a relcache invalidation signal for the target relation down insideone of the index_open calls we're doing. Since the target is open, wewould not drop the relcache entry, just reset its rd_indexvalid andrd_indexlist fields. But RelationGetIndexAttrBitmap() kept going, andwould eventually cache and return potentially-obsolete attribute bitmaps.The case where this matters is where the inval signal was from a CREATEINDEX CONCURRENTLY telling us about a new index on a formerly-unindexedcolumn. (In all other cases, the lock we hold on the target rel shouldprevent any concurrent change in index state.) Even just returning thestale attribute bitmap is not such a problem, because it shouldn't matterduring the transaction in which we receive the signal. What hurts iscaching the stale data, because it can survive into later transactions,breaking CREATE INDEX CONCURRENTLY's expectation that later transactionswill not create new broken HOT chains. The upshot is that there's a windowfor building corrupted indexes during CREATE INDEX CONCURRENTLY.This patch fixes the problem by rechecking that the set of index OIDsis still the same at the end of RelationGetIndexAttrBitmap() as it wasat the start. If not, we loop back and try again. That's a littlemore than is strictly necessary to fix the bug --- in principle, wecould return the stale data but not cache it --- but it seems like abad idea on general principles for relcache to return data it knowsis stale.There might be more hazards of the same ilk, or there might be a betterway to fix this one, but this patch definitely improves matters and seemsunlikely to make anything worse. So let's push it into today's releaseseven as we continue to study the problem.Pavan Deolasee and myselfDiscussion:https://postgr.es/m/CABOikdM2MUq9cyZJi1KyLmmkCereyGp5JQ4fuwKoyKEde_mzkQ@mail.gmail.com
1 parentfc7c21f commit32c893c

File tree

1 file changed

+30
-4
lines changed

1 file changed

+30
-4
lines changed

‎src/backend/utils/cache/relcache.c

Lines changed: 30 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -3811,8 +3811,10 @@ RelationGetIndexPredicate(Relation relation)
38113811
* we can include system attributes (e.g., OID) in the bitmap representation.
38123812
*
38133813
* Caller had better hold at least RowExclusiveLock on the target relation
3814-
* to ensure that it has a stable set of indexes. This also makes it safe
3815-
* (deadlock-free) for us to take locks on the relation's indexes.
3814+
* to ensure it is safe (deadlock-free) for us to take locks on the relation's
3815+
* indexes. Note that since the introduction of CREATE INDEX CONCURRENTLY,
3816+
* that lock level doesn't guarantee a stable set of indexes, so we have to
3817+
* be prepared to retry here in case of a change in the set of indexes.
38163818
*
38173819
* The returned result is palloc'd in the caller's memory context and should
38183820
* be bms_free'd when not needed anymore.
@@ -3823,6 +3825,7 @@ RelationGetIndexAttrBitmap(Relation relation, bool keyAttrs)
38233825
Bitmapset*indexattrs;
38243826
Bitmapset*uindexattrs;
38253827
List*indexoidlist;
3828+
List*newindexoidlist;
38263829
ListCell*l;
38273830
MemoryContextoldcxt;
38283831

@@ -3835,8 +3838,9 @@ RelationGetIndexAttrBitmap(Relation relation, bool keyAttrs)
38353838
returnNULL;
38363839

38373840
/*
3838-
* Get cached list of index OIDs
3841+
* Get cached list of index OIDs. If we have to start over, we do so here.
38393842
*/
3843+
restart:
38403844
indexoidlist=RelationGetIndexList(relation);
38413845

38423846
/* Fall out if no indexes (but relhasindex was set) */
@@ -3897,7 +3901,29 @@ RelationGetIndexAttrBitmap(Relation relation, bool keyAttrs)
38973901
index_close(indexDesc,AccessShareLock);
38983902
}
38993903

3900-
list_free(indexoidlist);
3904+
/*
3905+
* During one of the index_opens in the above loop, we might have received
3906+
* a relcache flush event on this relcache entry, which might have been
3907+
* signaling a change in the rel's index list. If so, we'd better start
3908+
* over to ensure we deliver up-to-date attribute bitmaps.
3909+
*/
3910+
newindexoidlist=RelationGetIndexList(relation);
3911+
if (equal(indexoidlist,newindexoidlist))
3912+
{
3913+
/* Still the same index set, so proceed */
3914+
list_free(newindexoidlist);
3915+
list_free(indexoidlist);
3916+
}
3917+
else
3918+
{
3919+
/* Gotta do it over ... might as well not leak memory */
3920+
list_free(newindexoidlist);
3921+
list_free(indexoidlist);
3922+
bms_free(uindexattrs);
3923+
bms_free(indexattrs);
3924+
3925+
gotorestart;
3926+
}
39013927

39023928
/*
39033929
* Now save copies of the bitmaps in the relcache entry. We intentionally

0 commit comments

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