Re: [HACKERS] Another nasty cache problem

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-30 19:25:29
Message-ID: 200001301925.OAA13522@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jo 2000-01-30 20:29:45 corel9
Previous Message Tom Lane 2000-01-30 18:22:05 Re: [HACKERS] Another nasty cache problem