I wrote:
>> I suspect that this is an instance of a generic problem with *all*
>> the SysCache tables, and perhaps the relcache as well: there is no
>> mechanism to ensure that the caches stay in sync with the underlying
>> relation during an abort.
Actually, there is such a mechanism: I find that the "shared
invalidation" manager has the right sorts of hooks into the SysCache
stuff. It appears that once a tuple has been committed, the SI code
will ensure that it gets flushed from all the backends' caches if it
is modified. The problem comes up when a backend creates a tuple,
causes it to be loaded into SysCache, and then aborts, all within
one transaction. The SI code doesn't handle that case, for reasons
that are not clear to me.
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Other backends don't see the rows until they are committed, but we do
> see them because they are part of our own transaction.
Yes, this seems to be a key part of the problem.
The fix I just committed seems to cure the known cases, but it is
not elegant. I now think that the *real* problem is somewhere in
the sinval code. But I'm not inclined to try to solve it for 6.5.
regards, tom lane
