| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Memoize: stale entry pointer after cache_store_tuple() |
| Date: | 2026-11-12 00:46:39 |
| Message-ID: | CAApHDvqC70L1Aog_PbSsvztqqi2hiUF_R1SF8QRVSpxgpc_+AQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 12 Nov 2026 at 01:15, Ilia Evdokimov
<ilya(dot)evdokimov(at)tantorlabs(dot)com> wrote:
> I found a case where Memoize rescans its inner plan even though the complete result for the requested key is already cached.
>
> When the cache exceeds its memory limit, Memoize removes older entries. Removing an entry from the hash table can move other entries to different buckets, including the entry currently being filled.
>
> The code that stores a tuple accounts for this movement and updates node->entry. However, its caller then marks the entry as complete using the old local pointer:
Interesting. Human or AI found?
Looks like this could cause misses that could be hits regardless of
singlerow mode. With singlerow mode, the wrong entry could be marked
as complete, but that entry should already be either complete or be an
unused bucket. So it was just a case of not marking the current entry
as complete. When not in singlerow mode, some other unrelated entry
could be *unmarked* as complete, which again could result in misses
that should be hits.
The fix looks fine. It's a bit annoying that I went to the trouble of
coding cache_store_tuple() to go to the trouble of discovering when
the simplehash code shuffled cache entries around without actually
correctly using the newly discovered bucket :-(
Pushed.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-11-12 01:37:28 | Re: [PATCH] pg_input_is_valid() reuses the first type name inside a PL/pgSQL loop |
| Previous Message | João Rito | 2026-11-12 00:36:58 | Re: Offline data checksum changes can cause incorrect checksum state on standbys |