From: | Bruce Momjian <maillist(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] Ye olde "relation doesn't quite exist" problem |
Date: | 1999-07-07 22:05:08 |
Message-ID: | 199907072205.SAA12300@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Added to TODO:
* elog() flushes cache, try invalidating just entries from current xact
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > OK, let me give two ideas here. First, we could create a linked list of
> > all cache additions that happen inside a transaction. If the
> > transaction aborts, we can invalidate all the cache entries in the list.
> > Second, we could just invalidate the entire cache on a transaction
> > abort. Third, we could somehow invalidate the cache on transaction
> > abort "only" if there was some system table modification in the
> > transaction. The third one seems a little harder.
>
> Yes, the second one was the quick-and-dirty answer that occurred to me.
> That would favor apps that seldom incur errors (no extra overhead to
> keep track of cache changes), but would be bad news for those that
> often incur errors (unnecessary cache reloads).
>
> Is there room in the SysCaches for the transaction ID of the last
> transaction to modify each entry? That would provide an easy and
> inexpensive way of finding the ones to zap when the current xact is
> aborted, I would think: abort would just scan all the caches looking
> for entries with the current xact ID, and invalidate only those entries.
> The cost in the no-error case would just be storing an additional
> field whenever an entry is modified; seems cheap enough. However,
> if there are a lot of different places in the code that can create/
> modify a cache entry, this could be a fair amount of work (and it'd
> carry the risk of missing some places...).
>
> > Seems like this not something for 6.5.
>
> I think we really ought to do *something*. I'd settle for the
> brute-force blow-away-all-the-caches answer for now, though.
>
> regards, tom lane
>
>
--
Bruce Momjian | http://www.op.net/~candle
maillist(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 | Tom Lane | 1999-07-07 22:06:13 | Re: [HACKERS] Help: fmgr_info: function 0: cache lookup failed |
Previous Message | Bruce Momjian | 1999-07-07 21:49:25 | Re: [HACKERS] refint (& others?) on current snapshot |