Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression
Date
Msg-id 1283406517.2609.15.camel@jdavis
Whole thread Raw
In response to Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression
List pgsql-hackers
On Wed, 2010-09-01 at 20:57 -0400, Tom Lane wrote:
> I wrote:
> > Probably the best fix would be to make typcache flushing fully
> > independent of the relcache, but that would mean making sure that all
> > ALTER TABLE variants that affect the rowtype will issue an explicit
> > typcache flush.  That seems a bit too invasive to be back-patchable.
> > I'm not entirely sure this sort of failure can occur without
> > RELCACHE_FORCE_RELEASE, but I'm definitely not sure it can't, so a
> > backpatchable fix would be nice.
> 
> After a bit more study it seems that there is a reasonably
> back-patchable approach to this.  We can continue to drive flushing of
> composite-type typcache entries off of relcache flush, but it has to
> occur when we do RelationCacheInvalidateEntry() or
> RelationCacheInvalidate() due to a SI invalidate event, not just
> anytime a relcache entry is closed.  We can do that by plugging in a
> callback function with CacheRegisterRelcacheCallback.
> 

I think I see how this fixes the problem, but I still don't completely
understand.

Why can't we just make a real copy of the tuple descriptor for the type
cache entry, rather than sharing it between the relcache and the type
cache?

Thank you for the quick response.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: leaky views, yet again
Next
From: KaiGai Kohei
Date:
Subject: Re: leaky views, yet again