Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Another nasty cache problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Another nasty cache problem
Date: 2000-01-31 01:52:22
Message-ID: 12631.949283542@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Perhaps the caches shouldn't store ctid?  Not sure.

> I am guilt of that.  There are a few place where I grab the tuple from
> the cache, then use that to update the heap.  I thought it was a nifty
> solution at the time.  I thought I used the CacheCopy calls for that,
> but I am not positive.  Even if I did, that doesn't help because the
> copy probably has an invalid tid at that point, thought I have opened
> the table. Maybe I have to make sure I open the table before geting the
> tid from the cache.

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.

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-01-31 01:55:14
Subject: Re: [HACKERS] freefuncs.c is never called from anywhere!?
Previous:From: Bruce MomjianDate: 2000-01-31 01:11:14
Subject: Re: [HACKERS] Re: ORDBMS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group