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
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 |