Horton

Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Date: 2023-06-28T20:54:43Z
Lists: pgsql-bugs 
Hi,

On 2023-06-28 15:52:28 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > If other sessions caused the tupledesc to be changed,
> > we should already hang onto the old definition via the
> > RememberToFreeTupleDescAtEOX() mechanism?
> 
> I believe the tupdesc in question is actually in the typcache,
> which doesn't have anything like RememberToFreeTupleDescAtEOX
> (which is a horrid hack anyway if you ask me).

It's in the typecache, but that just uses the relcache's tupledesc for
non-record composites. But looks like it doesn't suffice, because
TypeCacheRelCallback() releases the refcount the typecache held, regardless of
the tupledesc having changed meaningfully or not.

So even if there can't have been "important" changes to the tupledesc due to
locking, we end up with the newer tupledesc on a second lookup...


I agree that the RememberToFreeTupleDescAtEOX thing is a ugly hack, but I
don't think it's easy to come up with something good...


> We could probably make things better for this specific case by
> teaching the typcache not to replace a cached tupdesc unless its
> contents actually change.  But that just makes it harder to get
> to a bug instance; it's not a cure-all.

Yea :(.

Greetings,

Andres Freund

Commits

  1. Cache by-reference missing values in a long lived context

  2. Fix order of operations in ExecEvalFieldStoreDeForm().