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

On 2023-07-11 Tu 10:15, Andrew Dunstan wrote:
>
>
> 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.
>
>
>

Here it is. The nice thing here is that the code changes are entirely 
confined to heaptuple.c


cheers


andrew

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