Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, I have always been aware of this problem. The issue is that since
> cache entries are removed on a oldest-removed-first basis, I never
> thought that several cache lookups would be a problem.
They're not, under normal circumstances...
> However, a full reset of the cache could cause major problems. Is there
> a way to re-load the cache after the reset with the most recently cached
> entries? Seems that would be easier. However, your issue is probably
> that the new cache entries would have different locations from the old
> entries. Is it possible to delay the cache reset of the five most
> recent cache entries, and do them later?
I don't think that's a good answer; what if one of those entries is the
one that the SI messages wanted us to update? With a scheme like that,
you might be protecting a cache entry that actually isn't being used
anymore. With a refcount you'd at least know whether it was safe to
throw the entry away.
Of course this just begs the question of what to do when an SI update
message arrives for a tuple that is locked down by refcount. Maybe
we have to kick out an elog(ERROR) then. Could be messy.
regards, tom lane