Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression

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