Message-ID: <00f65092-0b44-4b3b-9b66-6ebee90def3a@postgrespro.ru>
Date: Mon, 26 Feb 2024 16:30:50 +0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: "type with xxxx does not exist" when doing ExecMemoize()
Content-Language: en-US
To: Tender Wang <tndrwang@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
References: 
 <CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com>
 <d3da9856-0394-48e6-9f41-543c589e9585@postgrespro.ru>
 <CAHewXNkSWMwGb_81wK3WCVx8-W-pOHC_AhiF=AeiRdG7sva4CQ@mail.gmail.com>
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
In-Reply-To: 
 <CAHewXNkSWMwGb_81wK3WCVx8-W-pOHC_AhiF=AeiRdG7sva4CQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/00f65092-0b44-4b3b-9b66-6ebee90def3a%40postgrespro.ru>
Precedence: bulk

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