Re: [HACKERS] Another nasty cache problem

> I believe we worked that out and fixed it a few months ago: it's safe
> to use the cache to find a tuple you want to update, if you open and
> lock the containing table *before* doing the cache lookup.  Then you
> know VACUUM's not running on that table (since you have it locked)
> and you have an up-to-date TID for the tuple (since the open+lock
> would have processed any pending shared-inval messages).  I went
> around and made sure that's true everywhere.

Good.

> What I was thinking about was adding code to the caches that would
> (a) maintain refcounts on cached tuples, (b) reread rather than
> discard a tuple if it is invalidated while refcount > 0, and (c)
> kick out an error if the reread shows that the tuple has in fact
> changed.  It seems that we would need to ignore the TID when deciding
> if a tuple has changed, however.

Yes, that is one solution.  We can do it the same way heap_fetch works.
It requires a Buffer pointer which it uses to return a value that calls
ReleaseBuffer() when completed.

However, would just throwing an elog on any cache invalidate on a cache
row looked up in the current transaction/command counter make more
sense?  Sometimes you are using that cache oid in some later actions
that really can't be proper unlocked at the end?  Would be less code.


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