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

On 2023-06-29 Th 15:25, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)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.
>
>

Yeah, Robert has just convinced me, so I'll do it like that. It doesn't
look too hard.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com