Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression - Mailing list pgsql-hackers

From Tom Lane
Subject Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression
Date
Msg-id 21237.1283433153@sss.pgh.pa.us
Whole thread Raw
In response to Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: git: uh-oh
Next
From: Michael Haggerty
Date:
Subject: Re: git: uh-oh