Re: [HACKERS] Another nasty cache problem

> 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.

Yep, that was my question.  You can re-load it, but if it is the one
that just got invalidated, what do you reload?  My guess is that you
keep using the same cache entry until the current transaction finishes,
at which point you can throw it away.

Now, if we did proper locking, no SI message could arrive for such an
entry.

My assumption is that these are mostly system cache entries, and they
rarely change, right?  If someone is operating on a table that gets an
SI entry, odds are that later on the system will fail because the table
is changed in some way, right?

Actually, don't we have a transaction id for the transaction that loaded
that cache entry.  We can add a transaction id to the cache record that
shows the transaction that last accessed that cache entry.  Then we can
say if any SI message comes in for a cache entry that was accessed by
the current transaction, we throw an elog.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026