From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Ye olde "relation doesn't quite exist" problem |
Date: | 1999-06-04 03:10:55 |
Message-ID: | 375743BF.CBF7BB84@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Isn't is tooooo bad for performance ?!
> 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.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-06-04 03:13:06 | Re: [HACKERS] Ye olde "relation doesn't quite exist" problem |
Previous Message | Tom Lane | 1999-06-04 03:10:33 | Re: [HACKERS] Re: Freezing docs for v6.5 |