On Fri, Jan 11, 2019 at 6:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> > Well, if we posit that the problems are limited to false Param-sharing,
> > my inclination is to fix it by simplifying rather than adding complexity.
> > To wit, let's just assign a new PARAM_EXEC slot for every NestLoopParam
> > and never try to share them. The argument that sharing them would work
> > for NLPs representing the same Var hinged on the assumption that nested
> > NestLoops would necessarily execute "in sync", which we now see is false
> > at least when Gathers are in between.
>
> Here's a POC patch for that. It's seriously ugly, but it passes
> check-world and I can no longer reproduce the problem using
> mockup_bug15577_v2.sql.
>
> At this point assign_nestloop_param_var and
> assign_nestloop_param_placeholdervar are dead code, and there's a bunch
> of incorrect comments in subselect.c, and I really need to refactor
> the division of labor between createplan.c and subselect.c (for one
> thing, this is an abuse of the documented purpose of
> SS_make_initplan_output_param). But functionally I think it does the
> right thing. Please test and verify that you no longer see the race
> condition.
I no longer see it here.
I can also see that Nested Loop with plan ID 0 is using paramno 2, and
the Nested Loop with plan ID 2 is using paramno 0.
--
Thomas Munro
http://www.enterprisedb.com