Skip site navigation (1) Skip section navigation (2)

Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression
Date: 2010-09-02 05:48:37
Message-ID: 1283406517.2609.15.camel@jdavis (view raw or flat)
Thread:
Lists: 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


In response to

Responses

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2010-09-02 07:33:52
Subject: Re: leaky views, yet again
Previous:From: KaiGai KoheiDate: 2010-09-02 04:30:03
Subject: Re: leaky views, yet again

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group