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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Haggerty 2010-09-02 13:40:25 Re: git: uh-oh
Previous Message Robert Haas 2010-09-02 13:02:18 Re: git: uh-oh