Re: "type with xxxx does not exist" when doing ExecMemoize()
Andrei Lepikhov <a.lepikhov@postgrespro.ru>
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
To: Tender Wang <tndrwang@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-26T05:38:09Z
Lists: pgsql-bugs, pgsql-hackers
Attachments
- test.sql (application/sql)
On 26/2/2024 09:52, Andrei Lepikhov wrote: > 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 Hmmm. I see the problem (test.sql in attachment for reproduction and results). We only detect it by the number of Hits: Cache Key: t1.x, (t1.t)::numeric Cache Mode: logical Hits: 0 Misses: 30 Evictions: 0 Overflows: 0 Memory Usage: 8kB We see no hits in logical mode and 100 hits in binary mode. We see 15 hits for both logical and binary mode if parameters are integer numbers - no problems with resetting expression context. Your patch resolves the issue for logical mode - I see 15 hits for integer and complex keys. But I still see 100 hits in binary mode. Maybe we still have a problem? What's more, why the Memoize node doesn't see the problem at all? -- regards, Andrei Lepikhov Postgres Professional
Commits
-
Fix incorrect accessing of pfree'd memory in Memoize
- 72b8507db2cc 14.12 landed
- 74530804fcb7 15.7 landed
- 348233cb128d 16.3 landed
- e62984647225 17.0 landed
-
Fix memory leak in Memoize code
- 0b053e78b599 17.0 cited