On 26/2/2024 15:14, Tender Wang wrote:
>
>
> Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru
> <mailto:a(dot)lepikhov(at)postgrespro(dot)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