Re: [HACKERS] Re: Freezing docs for v6.5 - Mailing list pgsql-hackers

> 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.

You know, I wonder if this is somewhat new.  The older code did more
sequential scans of the system tables.  We now do almost everything
through the syscache.

> 
> 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?)

No, that is not the problem.  If there exists a non-temp table with the
same name as the new temp table I am creating, I want the non-temp table
out of the system cache so my new table is seen on the next cache
lookup.

> 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.

Even if we knew how to do that, and I don't(though I tried), we still
have to have some way of knowing _which_ cache entries are invalidated
by the transaction rollback.  One idea was to mark the cache entries
with a transaction id of lookup, and remove those entries that are part
of an invalid transaction.

Other backends don't see the rows until they are committed, but we do
see them because they are part of our own transaction.

--  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