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

Commit8e2e266

Browse files
committed
Simplify call to rebuild relcache entry for indexes
RelationClearRelation(rebuild == true) calls RelationReloadIndexInfo()for indexes. We can rely on that in RelationIdGetRelation(), insteadof calling RelationReloadIndexInfo() directly. That simplifies thecode a little.In the passing, add a comment in RelationBuildLocalRelation()explaining why it doesn't call RelationInitIndexAccessInfo(). It'sbecause at index creation, it's called before the pg_index row hasbeen created. That's also the reason that RelationClearRelation()still needs a special case to go through the full-blown rebuild if theindex support information in the relcache entry hasn't been populatedyet.Reviewed-by: jian he <jian.universality@gmail.com>Discussion:https://www.postgresql.org/message-id/9c9e8908-7b3e-4ce7-85a8-00c0e165a3d6%40iki.fi
1 parent3974bc3 commit8e2e266

File tree

1 file changed

+17
-24
lines changed

1 file changed

+17
-24
lines changed

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

Lines changed: 17 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -2083,16 +2083,7 @@ RelationIdGetRelation(Oid relationId)
20832083
/* revalidate cache entry if necessary */
20842084
if (!rd->rd_isvalid)
20852085
{
2086-
/*
2087-
* Indexes only have a limited number of possible schema changes,
2088-
* and we don't want to use the full-blown procedure because it's
2089-
* a headache for indexes that reload itself depends on.
2090-
*/
2091-
if (rd->rd_rel->relkind==RELKIND_INDEX||
2092-
rd->rd_rel->relkind==RELKIND_PARTITIONED_INDEX)
2093-
RelationReloadIndexInfo(rd);
2094-
else
2095-
RelationClearRelation(rd, true);
2086+
RelationClearRelation(rd, true);
20962087

20972088
/*
20982089
* Normally entries need to be valid here, but before the relcache
@@ -2264,14 +2255,6 @@ RelationReloadIndexInfo(Relation relation)
22642255
!relation->rd_isvalid&&
22652256
relation->rd_droppedSubid==InvalidSubTransactionId);
22662257

2267-
/* Ensure it's closed at smgr level */
2268-
RelationCloseSmgr(relation);
2269-
2270-
/* Must free any AM cached data upon relcache flush */
2271-
if (relation->rd_amcache)
2272-
pfree(relation->rd_amcache);
2273-
relation->rd_amcache=NULL;
2274-
22752258
/*
22762259
* If it's a shared index, we might be called before backend startup has
22772260
* finished selecting a database, in which case we have no way to read
@@ -2600,15 +2583,19 @@ RelationClearRelation(Relation relation, bool rebuild)
26002583
return;
26012584

26022585
/*
2603-
* Even non-system indexes should not be blown away if they are open and
2604-
* have valid index support information. This avoids problems with active
2605-
* use of the index support information. As with nailed indexes, we
2606-
* re-read the pg_class row to handle possible physical relocation of the
2607-
* index, and we check for pg_index updates too.
2586+
* Indexes only have a limited number of possible schema changes, and we
2587+
* don't want to use the full-blown procedure because it's a headache for
2588+
* indexes that reload itself depends on.
2589+
*
2590+
* As an exception, use the full procedure if the index access info hasn't
2591+
* been initialized yet. Index creation relies on that: it first builds
2592+
* the relcache entry with RelationBuildLocalRelation(), creates the
2593+
* pg_index tuple only after that, and then relies on
2594+
* CommandCounterIncrement to load the pg_index contents.
26082595
*/
26092596
if ((relation->rd_rel->relkind==RELKIND_INDEX||
26102597
relation->rd_rel->relkind==RELKIND_PARTITIONED_INDEX)&&
2611-
relation->rd_refcnt>0&&
2598+
rebuild&&
26122599
relation->rd_indexcxt!=NULL)
26132600
{
26142601
if (IsTransactionState())
@@ -3720,6 +3707,12 @@ RelationBuildLocalRelation(const char *relname,
37203707
if (RELKIND_HAS_TABLE_AM(relkind)||relkind==RELKIND_SEQUENCE)
37213708
RelationInitTableAccessMethod(rel);
37223709

3710+
/*
3711+
* Leave index access method uninitialized, because the pg_index row has
3712+
* not been inserted at this stage of index creation yet. The cache
3713+
* invalidation after pg_index row has been inserted will initialize it.
3714+
*/
3715+
37233716
/*
37243717
* Okay to insert into the relcache hash table.
37253718
*

0 commit comments

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