I wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> I have attached regression.diffs after a "make check". The diffs don't
>> look trivial, and actually look quite strange to me.
> Hmm, sorta looks like that breaks something related to checking for
> composite types. That would be a bug. Will look.
So here is the culprit:
#0 0x00000000007c08e7 in flush_rowtype_cache (type_id=49022) at typcache.c:531
#1 0x00000000007b4797 in RelationClearRelation (relation=0x7fc490ccebe0, rebuild=0 '\000') at relcache.c:1929
#2 0x00000000007b4131 in RelationClose (relation=0x7fc490ccebe0) at relcache.c:1680
#3 0x0000000000472721 in relation_close (relation=0x7fc490ccebe0, lockmode=1) at heapam.c:1051
#4 0x00000000007c01fe in lookup_type_cache (type_id=49022, flags=64) at typcache.c:299
#5 0x00000000007c023f in lookup_rowtype_tupdesc_internal (type_id=49022, typmod=-1, noError=0 '\000') at
typcache.c:321
#6 0x00000000007c03e7 in lookup_rowtype_tupdesc_copy (type_id=49022, typmod=-1) at typcache.c:395
#7 0x00000000007cd087 in get_expr_result_type (expr=0x1395d08, resultTypeId=0x0, resultTupleDesc=0x7fffbd6e5830) at
funcapi.c:256
lookup_type_cache() opens the relcache entry to copy its tupdesc, does
so, and closes the relcache entry again. But then (if
RELCACHE_FORCE_RELEASE is on) we blow away the relcache entry ...
and RelationClearRelation carefully reaches around and blows away
the tupdesc in the typcache too!
So that's overly aggressive, but I'm not sure what's a simple fix for
it. If we just take out that flush_rowtype_cache call in
RelationClearRelation, I think we run the risk of the typcache not being
flushed when it needs to be, namely when an ALTER TABLE changes the
table's rowtype at an instant when some particular backend doesn't
have an active relcache entry for it.
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.
Thoughts?
regards, tom lane