Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Andres Freund <andres@anarazel.de>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-06-29T19:25:35Z
Lists: pgsql-bugs 
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-06-29 Th 10:26, Tom Lane wrote:
>> I'm a bit concerned about added
>> overhead, and about whether the hashtable needs invalidation support.
>> It might be better to key it off (relfilenode, attnum).

> re relfilenode: we don't have it in getmissingattr, so that would 
> involve looking it up or whacking around the API.

Yeah, I was afraid of that.

> re invalidation: that seems to suggest that the missing value could 
> change under us. I don't think it can, but if it can then more than just 
> this is broken. If not, how would invalidation affect us?

The scenario I'm afraid of is that we cache a missingval for table X,
then X gets dropped, then a new table Y gets created that by bad luck
has the same type OID as X did, then we add a column to Y that
requires a missingval, and now we have an entry in the hashtable that
matches Y but contains the wrong value.  Admittedly, it seems very
low probability that this would all happen within the span of one
transaction, so maybe we can get away with ignoring the case.  But
if we used relfilenode, we'd have at least a little more protection
because of the tombstone files that prevent immediate re-use of a
relfilenode OID.  I'm not sure that it'd be bulletproof even with
relfilenode, though.  Maybe we should bite the bullet and provide
invalidation based on a pg_type inval callback.

			regards, tom lane

Commits

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

  2. Fix order of operations in ExecEvalFieldStoreDeForm().