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
