Re: [HACKERS] Ye olde "relation doesn't quite exist" problem

I have dealt with this bug:

> 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

It is not real clear to me why the existing syscache invalidation
mechanism (CatalogCacheIdInvalidate() etc) fails to handle this case,
but it doesn't.  Perhaps it is because the underlying pg_class tuple
never actually makes it to "confirmed good" status, so the SI code
figures it can ignore it.

I think the correct place to handle the problem is in
SystemCacheRelationFlushed() in catcache.c.  That routine is called by
RelationFlushRelation() (which does the same task for the relcache).
Unfortunately, it was only handling one aspect of the cache-update
problem: it was cleaning out the cache associated with a system table
when the *system table's* relcache entry was flushed.  It didn't scan
the cache contents to see if any of the records are associated with a
non-system table that's being flushed.

For the moment, I have made it call ResetSystemCache() --- that is, just
flush *all* the cache entries.  Scanning the individual entries to find
the ones referencing the given relID would require knowing exactly which
column to look in for each kind of system cache, which is more knowledge
than catcache.c actually has.  Eventually we could improve it.

This means it is no longer necessary for heap.c or index.c to call
ResetSystemCache() when handling a temp table --- their calls to
RelationForgetRelation are sufficient.  I have applied those changes
as well.
        regards, tom lane