database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-12 21:01:52 +03:00
Code Activity

Revise sinval code to remove no-longer-used tuple TID from inval messages.

Browse Source 
This requires adjusting the API for syscache callback functions: they now
get a hash value, not a TID, to identify the target tuple.  Most of them
weren't paying any attention to that argument anyway, but plancache did
require a small amount of fixing.

Also, improve performance a trifle by avoiding sending duplicate inval
messages when a heap_update isn't changing the catcache lookup columns.
This commit is contained in:
Tom Lane
2011-08-16 19:27:46 -04:00
parent 632ae6829f
commit b5282aa893
19 changed files with 210 additions and 211 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
src/backend/access/heap/heapam.c
View File

@ -2028,7 +2028,7 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
* the heaptup data structure is all in local memory, not in the shared
* buffer.
*/
CacheInvalidateHeapTuple(relation, heaptup);
CacheInvalidateHeapTuple(relation, heaptup, NULL);
pgstat_count_heap_insert(relation);
@ -2354,7 +2354,7 @@ l1:
* boundary. We have to do this before releasing the buffer because we
* need to look at the contents of the tuple.
*/
CacheInvalidateHeapTuple(relation, &tp);
CacheInvalidateHeapTuple(relation, &tp, NULL);
/* Now we can release the buffer */
ReleaseBuffer(buffer);
@ -2930,10 +2930,13 @@ l2:
/*
* Mark old tuple for invalidation from system caches at next command
* boundary. We have to do this before releasing the buffer because we
* need to look at the contents of the tuple.
* boundary, and mark the new tuple for invalidation in case we abort.
* We have to do this before releasing the buffer because oldtup is in
* the buffer. (heaptup is all in local memory, but it's necessary to
* process both tuple versions in one call to inval.c so we can avoid
* redundant sinval messages.)
*/
CacheInvalidateHeapTuple(relation, &oldtup);
CacheInvalidateHeapTuple(relation, &oldtup, heaptup);
/* Now we can release the buffer(s) */
if (newbuf != buffer)
@ -2944,14 +2947,6 @@ l2:
if (BufferIsValid(vmbuffer))
ReleaseBuffer(vmbuffer);
/*
* If new tuple is cachable, mark it for invalidation from the caches in
* case we abort. Note it is OK to do this after releasing the buffer,
* because the heaptup data structure is all in local memory, not in the
* shared buffer.
*/
CacheInvalidateHeapTuple(relation, heaptup);
/*
* Release the lmgr tuple lock, if we had it.
*/
@ -3659,9 +3654,14 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
UnlockReleaseBuffer(buffer);
/* Send out shared cache inval if necessary */
/*
* Send out shared cache inval if necessary. Note that because we only
* pass the new version of the tuple, this mustn't be used for any
* operations that could change catcache lookup keys. But we aren't
* bothering with index updates either, so that's true a fortiori.
*/
if (!IsBootstrapProcessingMode())
CacheInvalidateHeapTuple(relation, tuple);
CacheInvalidateHeapTuple(relation, tuple, NULL);
}