Re: Check lateral references within PHVs for memoize cache keys - Mailing list pgsql-hackers

From David Rowley
Subject Re: Check lateral references within PHVs for memoize cache keys
Date
Msg-id CAApHDvr4qs6VxykigB2MtECcc=NAmHejxJZ7JoM3zf28wG6nhA@mail.gmail.com
Whole thread Raw
In response to Re: Check lateral references within PHVs for memoize cache keys  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Check lateral references within PHVs for memoize cache keys  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
On Fri, 30 Dec 2022 at 16:00, Richard Guo <guofenglinux@gmail.com> wrote:
>
> On Fri, Dec 9, 2022 at 5:16 PM Richard Guo <guofenglinux@gmail.com> wrote:
>>
>> Actually we do have checked PHVs for lateral references, earlier in
>> create_lateral_join_info.  But that time we only marked lateral_relids
>> and direct_lateral_relids, without remembering the lateral expressions.
>> So I'm wondering whether we can fix that by fetching Vars (or PHVs) of
>> lateral references within PlaceHolderVars and remembering them in the
>> baserel's lateral_vars.
>>
>> Attach a draft patch to show my thoughts.

I'm surprised to see that it's only Memoize that ever makes use of
lateral_vars. I'd need a bit more time to process your patch, but one
additional thought I had was that I wonder if the following code is
still needed in nodeMemoize.c

if (bms_nonempty_difference(outerPlan->chgParam, node->keyparamids))
    cache_purge_all(node);

Ideally, that would be an Assert failure, but possibly we should
probably still call cache_purge_all(node) after Assert(false) so that
at least we'd not start returning wrong results if we've happened to
miss other cache keys. I thought maybe something like:

if (bms_nonempty_difference(outerPlan->chgParam, node->keyparamids))
{
    /*
     * Really the planner should have added all the possible parameters to
     * the cache keys, so let's Assert fail here so we get the memo to fix
     * that can fix that.  On production builds, we'd better purge the
     * cache to account for the changed parameter value.
     */
    Assert(false);

    cache_purge_all(node);
}

I've not run the tests to ensure we don't get an Assert failure with
that, however.

All that cache_purge_all code added in 411137a42 likely was an
incorrect fix for what you've raised here, but it's maybe a good
failsafe to keep around even if we think we've now found all possible
parameters that can invalidate the memorized results.

David



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Improve logging when using Huge Pages
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Logical replication timeout problem