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

Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression

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

The issue isn't really about whether we're sharing the physical copy of
the tupdesc.  The problem the code is trying to deal with is making sure
that the typcache's copy gets thrown away (so it can be refreshed on
next use) when the relation's rowtype changes, due to ALTER TABLE ADD
COLUMN for example.  So we need to do that whenever we get a SI inval
event for the rel.  We were driving that purely off of relcache
flushes, which meant that discarding a relcache entry had to force a
typcache flush, since nothing would happen if a SI inval arrived at an
instant where we had no relcache entry for the rel.  Now the typcache is
wired directly to the SI inval events, so it'll get a call whether there
is a corresponding relcache entry or not.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Michael HaggertyDate: 2010-09-02 13:40:25
Subject: Re: git: uh-oh
Previous:From: Robert HaasDate: 2010-09-02 13:02:18
Subject: Re: git: uh-oh

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