From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Another nasty cache problem |
Date: | 2000-01-31 02:18:51 |
Message-ID: | 200001310218.VAA24603@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Ed Loehr | 2000-01-31 04:49:25 | [HACKERS] float4 confused as int?? |
Previous Message | Tom Lane | 2000-01-31 01:55:14 | Re: [HACKERS] freefuncs.c is never called from anywhere!? |