I have committed changes to keep reference counts for system cache entries.
This should eliminate the issues we've had with cache entries sometimes
getting dropped while still in use. Some notes:
1. The routine formerly called SearchSysCacheTuple is now SearchSysCache().
It increments the reference count on the returned cache entry. You must
drop the reference count when done using the cache entry, so the typical
call scenario is now something like
tuple = SearchSysCache(...);
if (HeapTupleIsValid(tuple))
{
... use tuple ...
ReleaseSysCache(tuple);
}
2. If a cache inval message arrives for a cache entry with refcount > 0,
the cache entry will not be dropped until the refcount goes to zero.
However, it will immediately be marked "dead" and so will not be found
by subsequent cache searches.
3. It turned out not to be hard to make the parser drop reference counts
when done with cache entries, so I went over to a hard-and-fast rule
that everyone must drop acquired refcounts. If you don't, you'll get
an annoying NOTICE at commit time, just like for buffer refcount leaks.
4. There are several convenience routines for common usage patterns:
* SearchSysCacheCopy() --- formerly SearchSysCacheTupleCopy() --- still
exists, although the need for it is less than before. You do NOT need
this routine just to hang onto a reference to a cache entry for awhile.
You use it if you want to update the tuple and need a modifiable copy
to scribble on. When you use this routine, you get back a palloc'd
tuple (free it with heap_freetuple), and the original cache entry does
not have its refcount bumped.
* SearchSysCacheExists() just probes for the existence of a tuple via
the cache; it returns true or false without bumping the refcount.
* GetSysCacheOid() returns the cache entry's OID, or InvalidOid if no
entry found, leaving the refcount un-bumped.
* There are some other new convenience routines too in parse_oper.c,
parse_type.c, and lsyscache.c, to reduce the number of places that
have to bother with the full SearchSysCache/ReleaseSysCache protocol.
regards, tom lane
