Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression

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.

Because the callback will only have the relation OID not the type OID,
it will have to scan the whole TypeCacheHash to see if there's a
matching entry.  However, that's not as bad as it sounds, because there
aren't likely to be very many entries in that hashtable.  I put in some
quick-hack instrumentation to see how big the table gets during the
regression tests, and find that of the hundred-odd backends launched
during the tests, none get above 26 typcache entries, and only 8 get as
many as 10 entries.  Based on those numbers, I'm not sure it'd ever be
worth adding the additional infrastructure to allow a direct hash lookup
instead.
        regards, tom lane