Re: bug: query returns different result with and without memoization.

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Yilin Zhang <jiezhilove(at)126(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: bug: query returns different result with and without memoization.
Date: 2026-11-02 08:58:03
Message-ID: CAMbWs4_CE9RrQi=GXzbAkRNfN0=8AcPc=20B17s9F=SJvswDsg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 2, 2026 at 11:33 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Codex reported me that, after this change, the same query can fail with
> enable_memoize enabled but succeed with it disabled, as shown below.
> Is this a bug?

Thanks for the report! Yes, both are bugs, and they have the same
cause. When looking for Params to make cache keys of, we collect
every PARAM_EXEC Param we find, but only those supplied by outer query
levels are safe to evaluate as cache keys.

In your first query, the output Param of the ALL SubPlan is made a
cache key, but it has no value outside the SubPlan's testexpr, hence
the "plan should not reference subplan's variable" error. In your
second query, the initPlan's output Param is made a cache key, so
Memoize runs the initPlan when it evaluates the cache keys, even
though the CASE arm that needs it is never taken.

Attached is a patch that fixes it by making cache keys only of the
Params listed in some outer query level's plan_params. I plan to
back-patch it to v14.

- Richard

Attachment Content-Type Size
v1-0001-Make-Memoize-cache-keys-only-of-Params-from-outer.patch application/octet-stream 8.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2026-11-02 09:01:38 Honor inherited ownership when finishing prepared transactions
Previous Message vignesh C 2026-11-02 08:51:58 Re: WAL record CRC calculated incorrectly because of underlying buffer modification