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

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.

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

Greetings,

Andres Freund