Re: Memoize: stale entry pointer after cache_store_tuple()

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

In response to

Browse pgsql-hackers by date

  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