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

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.

>
> I kinda wonder if this isn't basically the start of a "string interning" style
> infrastructure, except for more types than just strings... I've wondered about
> having that quite a few times.

maybe.

cheers

andrew

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