Thread: Re: "type with xxxx does not exist" when doing ExecMemoize()
Andrei Lepikhov <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.
--
regards,
Andrei Lepikhov
Postgres Professional
Tender Wang
OpenPie: https://en.openpie.com/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