Re: [HACKERS] Ye olde "relation doesn't quite exist" problem
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Ye olde "relation doesn't quite exist" problem |
Дата | |
Msg-id | 199907072205.SAA12300@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Ye olde "relation doesn't quite exist" problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Added to TODO: * elog() flushes cache, try invalidating just entries from current xact > Bruce Momjian <maillist@candle.pha.pa.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@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
В списке pgsql-hackers по дате отправления: