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

On 2023-07-10 Mo 15:51, Andres Freund wrote:
> Hi,
>
> On 2023-07-08 08:48:00 -0400, Andrew Dunstan wrote:
>> On 2023-07-02 Su 22:15, Andrew Dunstan wrote:
>>>>>> 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.
> It's not really bound by that, because the set of rows can change over
> time. Particularly with temp tables.

How many times are people going to add a new column with a non-null
default to a temp table? Usually you know the shape you want for a temp
table when you create it, I should think. Even in a long-running
pgbouncer session I wouldn't expect this to balloon substantially.

>
>
>> The thread seems to have died down a bit. Do we have a consensus on Tom's
>> approach?
> I guess so. It's far from pretty, but nobody really has come up with something
> better.
>

OK, I'll send a revised patch.

cheers

andrew

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