Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Elvis Pranskevichus <elprans@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2021-10-05T01:59:40Z
Lists: pgsql-bugs
On Tue, 5 Oct 2021 at 14:21, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Elvis Pranskevichus <elprans@gmail.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
Commits
-
Flush Memoize cache when non-key parameters change, take 2
- c2dc7b9e1503 14.2 landed
- 411137a42921 15.0 landed
-
Flush Memoize cache when non-key parameters change
- f94edb06ab60 14.2 landed
- 1050048a3157 15.0 landed