Vadim Mikheev <vadim@krs.ru> writes:
>> On Thu, 3 Jun 1999, Tom Lane wrote:
>>>> Bruce seemed to think that we could just flush the sys caches and
>>>> relation cache completely during xact abort.
> Could you remember me what's the problem with cache?
The reported problem was that if a new relation is created, and then
the transaction is aborted, the SysCache entry for the new relation's
pg_class entry doesn't get removed. For example:
test=> create table bug1 (f1 int28 primary key);
ERROR: Can't find a default operator class for type 22.
-- That's expected, since we have no index support for int28. But now:
test=> create table bug1 (f1 int28);
ERROR: Relation 'bug1' already exists
The second try fails because it finds an entry for 'bug1' in the
RELNAME SysCache, which was made before the create-index step of
CREATE TABLE failed. That entry should not be there anymore.
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. So there could be all kinds of weird
misbehavior following an error, if the transaction added or modified
a SysCache entry before failing.
Bruce has a related problem for temp tables: he needs to make sure that
their entries in these caches go away at end of transaction. (BTW, what
makes that happen if the transaction is aborted rather than committed?)
There is probably a better way to fix it than the brute force "flush the
whole cache" method --- for example, how do cache entries get deleted
normally, if the underlying relation entry is deleted? Maybe that
mechanism could be used. But I doubt we have time to do anything fancy
for 6.5.
regards, tom lane