Horton

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

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-06-30T13:23:13Z
Lists: pgsql-bugs 
On 2023-06-30 Fr 08:46, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> On 2023-06-29 Th 18:41, Tom Lane wrote:
>>> Why not make the hash key be the value
>>> itself?  Wrap it in a bytea perhaps to avoid needing a bespoke
>>> hash function.
>> Not sure I understand.
> Say the missingval for a particular column is text 'abc'.
> We don't actually care which column it is, all we need is a
> copy of that datum that will stay put for the rest of the
> transaction.  So I'm thinking that the lookup key for the
> hash table should actually be the contents of the datum,
> and we don't need to store anything else at all.  (If we
> happen to have two columns with the same missingval, they
> can perfectly well share this hash entry.)  Then there's
> no question of invalidation, or at least the existing
> invalidation mechanisms for tupdescs do all we need.
>
> 			


OK, I get it. Do we have a routine to wrap a Datum in a bytea, or do I 
need to write one? It's slightly amusing that the original patch for 
fast defaults stored the missing value as a bytea, but someone (Andres 
IIRC) preferred that we store it as a one element array, so that's what 
we went with.


cheers


andrew

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

Commits

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

  2. Fix order of operations in ExecEvalFieldStoreDeForm().