Re: "type with xxxx does not exist" when doing ExecMemoize()

On 26/2/2024 15:14, Tender Wang wrote:
> 
> 
> Andrei Lepikhov <a.lepikhov@postgrespro.ru 
> <mailto:a.lepikhov@postgrespro.ru>> 于2024年2月26日周一 10:57写道：
> 
>     On 25/2/2024 20:32, Tender Wang wrote:
>      > I think in prepare_probe_slot(), should called datumCopy as the
>     attached
>      > patch does.
>      >
>      > Any thoughts? Thanks.
>     Thanks for the report.
>     I think it is better to invent a Runtime Memory Context; likewise,
>     it is
>     already designed in IndexScan and derivatives. Here, you just allocate
>     the value in some upper memory context.
> 
>     Also, I'm curious why such a trivial error hasn't been found for a
>     long time
> 
>    I analyze this issue again. I found that the forms of qual in 
> Memoize.sql(regress) are all like this:
> 
>    table1.c0 OP table2.c0
> If table2.c0 is the param value, the probeslot->tts_values[i] just store 
> the pointer.  The memorycontext of this pointer is
> ExecutorContext not ExprContext, Reset ExprContext doesn't change the 
> data of probeslot->tts_values[i].
> So such a trivial error hasn't been found before.
I'm not happy with using table context for the probeslot values. As I 
see, in the case of a new entry, the cache_lookup copies data from this 
slot. If a match is detected, the allocated probeslot memory piece will 
not be freed up to hash table reset. Taking this into account, should we 
invent some new runtime context?

-- 
regards,
Andrei Lepikhov
Postgres Professional