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

On 2023-07-02 Su 22:15, Andrew Dunstan wrote:
>
>
> On 2023-07-02 Su 18:13, Andres Freund wrote:
>> Hi,
>>
>> On 2023-07-02 17:57:03 -0400, Tom Lane wrote:
>>> Andres Freund<andres(at)anarazel(dot)de> writes:
>>>> Isn't that going to break the assumption that the key is unique within a
>>>> transaction?
>>> Huh? "abc" is "abc", no matter what. At least if Andrew did what
>>> I suggested (I didn't look at the patch yet).
>> Yea, I think that was a brainfart after too briefly skimming the code.
>>
>>
>>>> Separately, will this work correctly with procedures keeping values alive
>>>> across transactions?
>>> That might be an issue. But couldn't we make this cache just live for
>>> the life of the process? It's unlikely to get large.
>> I don't have a good handle about how big it'd end up being in some of the less
>> common workloads. I can imagine workloads with temp tables or such churning
>> through a lot of default values - often the "keyed by value" approach will
>> save the day, but I imagine not always.
>
> The maximum number of entries in the table is the number of
> pg_attribute rows with atthasmissing = true and attbyval = false. In
> practice I suspect that's mostly going to be fairly low.
>
>
>> .oO(Perhaps we need to add a boehm style GC ... No.)
>>
>> Perhaps we could defer resetting the cache to when we're not inside a
>> procedure?
>
>
> I'm kinda leaning towards Tom's suggestion to just make it
> session-persistent.
>
>
>

The thread seems to have died down a bit. Do we have a consensus on
Tom's approach?

cheers

andrew

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