From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>,
  Bartosz Polnik <bartoszpolnik@gmail.com>,
  PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15577: Query returns different results when executed
 multiple times
In-Reply-To: 
 <CAEepm=0ZqJp2nXRZf8e9ys6Utyu96QVy0=L8Q=-2UoDxwY=smA@mail.gmail.com>
	(Thomas Munro's message of "Thu, 10 Jan 2019 09:20:42 +1300")
Message-ID: <87k1jdpniz.fsf@news-spur.riddles.org.uk>
References: <15577-ca61ab18904af852@postgresql.org>
	<CAKJS1f8kLijpf-EKHLL7yJ2KJy9-FWNQfXBuNtToVTPkW_Ue+w@mail.gmail.com>
	<CAM37Zev2xUezKc0XZFPfi=BtH+of+fqTAYUCJJuf+4Pc6u4G7g@mail.gmail.com>
	<CAEepm=0yv2qNDM_JfiakqQO3EqYNhQZjNCAX=fK8Cuhz6_RO4Q@mail.gmail.com>
	<CAM37ZetJ-R5De+aTfZV8+BE_KzqbajF3gjv_t1DGsS853aDc0Q@mail.gmail.com>
	<CAEepm=15_MWhhp-Pg6rW1whuXrBTJ-gM=w+2t-Qk-VQHgniG0w@mail.gmail.com>
	<CAM37ZevSHt0pdKhZ_Bu7nDoMMWSDsJaaPUPR_ApowoFida4fcA@mail.gmail.com>
	<CAEepm=1QU7HpJSGhBkfFwKC_wW6fCTADeHymA7ngzszJRM39bw@mail.gmail.com>
	<CAM37Zeu1gv=PswA-C4WeCN13KrrXcD9s1mTdaTuVTKjV=aLoiA@mail.gmail.com>
	<CAEepm=34FwV5W3qoz29_bS1uodKkN1wS-P_9V429JUjjGKwopg@mail.gmail.com>
	<CAM37ZeuWGV_58O8MeH0TfqBiK0JUONPhHs2=YM2MR61K2E=v9Q@mail.gmail.com>
	<CAKJS1f8OZteLVbmKyoTuC7wY=fzZ+jW=gFV=0NoXS0AvfbOZ2g@mail.gmail.com>
	<CAEepm=2MYvOvsA7YY-9kU0JT-2Bn51N-YjGq1mDi4GOeR=0nJA@mail.gmail.com>
	<CAEepm=3s70u7-E9aSdsSq+_S_cm2GnT4Tk3_vC81PDxe=hCFRw@mail.gmail.com>
	<CAKJS1f_-bU1rMby_qYXOvyAf9Mz8JEojA2tat1iU7mhdrySYoA@mail.gmail.com>
	<CAEepm=3q=22Stv6QTR+ijWorWYMFRPC=T=hM9iJPMxgpTOE55A@mail.gmail.com>
	<CAM37Zeshup0OkzJ2z=8_jBPrv-=dQZvs+v0HDmKnFf4wLn7jzQ@mail.gmail.com>
	<CAEepm=0eviDVN2n=Dr7FegnJ69w3Z+EaB=CBV5Y9HXLN_HwXKQ@mail.gmail.com>
	<CAEepm=2UuWkK-tUZMK=SqJ8Qn3jX0jTpE=wk5KKSSJB0gYzSXQ@mail.gmail.com>
	<CAKJS1f8zFL8539hpy_gBV3JOcNRqhb1wVVhuVkp_H_E_qJU_iw@mail.gmail.com>
	<CAEepm=0ZqJp2nXRZf8e9ys6Utyu96QVy0=L8Q=-2UoDxwY=smA@mail.gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix)
Date: Wed, 09 Jan 2019 21:04:05 +0000
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

>>>>> "Thomas" == Thomas Munro <thomas.munro@enterprisedb.com> writes:

 Thomas> So it's not the reading of the tuple queue per se, but the
 Thomas> resulting visit to a higher part of the plan when the Gather
 Thomas> node emits a tuple. It can't be right that plan id 2 and plan
 Thomas> id 0 are both using paramno 0, can it? I'm not too familiar
 Thomas> with the planner code that allocates those but will go and poke
 Thomas> at it.

Looks like this isn't a new bug, either; I can reproduce it on 10.x.

So I think you're right to finger the planner's allocation of params as
the culprit. Looking at replace_nestloop_params_mutator, it's keeping a
list of nestloop params in root->curOuterParams (thus, globally to the
whole subquery being planned), and it assumes that if equal() is true
between the value of an existing nestloop param (which must be a Var)
and the Var for the one it's trying to create, then it's ok to use the
existing one.

But clearly this can't work if one param is referenced both inside and
outside a Gather, because while they will compare equal for Vars, they
won't actually have the same value thanks to rows coming in from
workers.

-- 
Andrew (irc:RhodiumToad)