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

Commit632ae68

Browse files
committed
Forget about targeting catalog cache invalidations by tuple TID.
The TID isn't stable enough: we might queue an sinval event before a VACUUMFULL, and then process it afterwards, when the target tuple no longer hasthe same TID. So we must invalidate entries on the basis of hash valueonly. The old coding can be shown to result in various bizarre,hard-to-reproduce errors in the presence of concurrent VACUUM FULLs onsystem catalogs, and could easily result in permanent catalog corruption,up to and including complete loss of tables.This commit is just a minimal fix that removes the unsafe comparison.We should remove transmission of the tuple TID from sinval messagesaltogether, and then arrange to suppress the extra message in the commoncase of a heap_update that doesn't change the key hashvalue. But that'sgoing to be much more invasive, and will only produce a probably-marginalperformance gain, so it doesn't seem like material for a back-patch.Back-patch to 9.0. Before that, VACUUM FULL refused to do any tuple movingif it found any INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples (andCLUSTER would give up altogether), so there was no risk of moving a tuplethat might be the subject of an unsent sinval message.
1 parentf4d7f1a commit632ae68

File tree

1 file changed

+14
-21
lines changed

1 file changed

+14
-21
lines changed

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

Lines changed: 14 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -423,18 +423,19 @@ CatCacheRemoveCList(CatCache *cache, CatCList *cl)
423423
/*
424424
*CatalogCacheIdInvalidate
425425
*
426-
*Invalidate entries in the specified cache, given a hash value and
427-
*item pointer. Positive entries are deleted if they match the item
428-
*pointer. Negative entries must be deleted if they match the hash
429-
*value (since we do not have the exact key of the tuple that's being
430-
*inserted).But this should only rarely result in loss of a cache
431-
*entry that could have been kept.
426+
*Invalidate entries in the specified cache, given a hash value.
432427
*
433-
*Note that it's not very relevant whether the tuple identified by
434-
*the item pointer is being inserted or deleted.We don't expect to
435-
*find matching positive entries in the one case, and we don't expect
436-
*to find matching negative entries in the other; but we will do the
437-
*right things in any case.
428+
*We delete cache entries that match the hash value, whether positive
429+
*or negative. We don't care whether the invalidation is the result
430+
*of a tuple insertion or a deletion.
431+
*
432+
*We used to try to match positive cache entries by TID, but that is
433+
*unsafe after a VACUUM FULL on a system catalog: an inval event could
434+
*be queued before VACUUM FULL, and then processed afterwards, when the
435+
*target tuple that has to be invalidated has a different TID than it
436+
*did when the event was created. So now we just compare hash values and
437+
*accept the small risk of unnecessary invalidations due to false matches.
438+
*(The ItemPointer argument is therefore useless and should get removed.)
438439
*
439440
*This routine is only quasi-public: it should only be used by inval.c.
440441
*/
@@ -496,11 +497,7 @@ CatalogCacheIdInvalidate(int cacheId,
496497

497498
nextelt=DLGetSucc(elt);
498499

499-
if (hashValue!=ct->hash_value)
500-
continue;/* ignore non-matching hash values */
501-
502-
if (ct->negative||
503-
ItemPointerEquals(pointer,&ct->tuple.t_self))
500+
if (hashValue==ct->hash_value)
504501
{
505502
if (ct->refcount>0||
506503
(ct->c_list&&ct->c_list->refcount>0))
@@ -695,12 +692,8 @@ CatalogCacheFlushCatalog(Oid catId)
695692

696693
for (cache=CacheHdr->ch_caches;cache;cache=cache->cc_next)
697694
{
698-
/* We can ignore uninitialized caches, since they must be empty */
699-
if (cache->cc_tupdesc==NULL)
700-
continue;
701-
702695
/* Does this cache store tuples of the target catalog? */
703-
if (cache->cc_tupdesc->attrs[0]->attrelid==catId)
696+
if (cache->cc_reloid==catId)
704697
{
705698
/* Yes, so flush all its contents */
706699
ResetCatalogCache(cache);

0 commit comments

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