Fix up flushing of composite-type typcache entries to be driven directly by
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 2 Sep 2010 03:16:59 +0000 (03:16 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 2 Sep 2010 03:16:59 +0000 (03:16 +0000)
commite0664d5cdcd555a163268b532d68304083cd737a
tree6664e3157705a8b73268ee9f8bd3ebb5528254c1
parent27fddbadc474e8a8690abdf91a9c1e06fff548d3
Fix up flushing of composite-type typcache entries to be driven directly by
SI invalidation events, rather than indirectly through the relcache.

In the previous coding, we had to flush a composite-type typcache entry
whenever we discarded the corresponding relcache entry.  This caused problems
at least when testing with RELCACHE_FORCE_RELEASE, as shown in recent report
from Jeff Davis, and might result in real-world problems given the kind of
unexpected relcache flush that that test mechanism is intended to model.

The new coding decouples relcache and typcache management, which is a good
thing anyway from a structural perspective.  The cost is that we have to
search the typcache linearly to find entries that need to be flushed.  There
are a couple of ways we could avoid that, but at the moment it's not clear
it's worth any extra trouble, because the typcache contains very few entries
in typical operation.

Back-patch to 8.2, the same as some other recent fixes in this general area.
The patch could be carried back to 8.0 with some additional work, but given
that it's only hypothetical whether we're fixing any problem observable in
the field, it doesn't seem worth the work now.
src/backend/utils/cache/relcache.c
src/backend/utils/cache/typcache.c
src/include/utils/typcache.h