Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Elvis Pranskevichus <elprans(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize
Date: 2021-10-05 01:59:40
Message-ID: CAApHDvru_idyPg4PvYk3HVnhiHwHq1uHe5YCfnaFD2GWGHyUEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, 5 Oct 2021 at 14:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Elvis Pranskevichus <elprans(at)gmail(dot)com> writes:
> > On Monday, October 4, 2021 5:14:47 PM PDT David Rowley wrote:
> >>> It appears a combination of Merge Semi Join and Memoize in
> >>> PostgreSQL 14 produces incorrect results on a particular query.
>
> > It seems like a very particular set of stats is causing the plan there,
> > as running ANALYZE turns the query into a Nested Loop Semi Join.
>
> Surely this plan tree is broken on its face? The inner side of
> a mergejoin has to be able to support mark/restore, and nestloop
> doesn't (cf ExecSupportsMarkRestore, as well as assertions in
> nodeNestloop). It looks to me like somebody removed an essential
> plan-time check.

Couldn't that just be because it's a Merge Semi Join and there's not
really any need to rewind the inner side if all join clauses are merge
join clauses, aka:

if ((path->jpath.jointype == JOIN_SEMI ||
path->jpath.jointype == JOIN_ANTI ||
extra->inner_unique) &&
(list_length(path->jpath.joinrestrictinfo) ==
list_length(path->path_mergeclauses)))
path->skip_mark_restore = true;

?

David

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Mark Dilger 2021-10-05 03:19:02 Re: BUG #17212: pg_amcheck fails on checking temporary relations
Previous Message Tom Lane 2021-10-05 01:21:21 Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize