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@anarazel.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