Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ghMyt-0006ml-Pk for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Jan 2019 23:09:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ghMys-0003aV-Ax for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Jan 2019 23:09:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ghMys-0003aO-4m for pgsql-bugs@lists.postgresql.org; Wed, 09 Jan 2019 23:09:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ghMyl-0005GT-Ah for pgsql-bugs@lists.postgresql.org; Wed, 09 Jan 2019 23:09:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x09N9aY5031334; Wed, 9 Jan 2019 18:09:36 -0500 From: Tom Lane To: Thomas Munro cc: Andrew Gierth , David Rowley , Bartosz Polnik , PostgreSQL mailing lists Subject: Re: BUG #15577: Query returns different results when executed multiple times In-reply-to: References: <15577-ca61ab18904af852@postgresql.org> <87k1jdpniz.fsf@news-spur.riddles.org.uk> Comments: In-reply-to Thomas Munro message dated "Thu, 10 Jan 2019 10:46:25 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31332.1547075376.1@sss.pgh.pa.us> Date: Wed, 09 Jan 2019 18:09:36 -0500 Message-ID: <31333.1547075376@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > On Thu, Jan 10, 2019 at 10:04 AM Andrew Gierth > wrote: >> 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. > But if they used different params, there could be different problems, > no? It's logically the same var. As far as I can think at the moment, there's no problem with having multiple nestloop Params referencing the "same" Var. It could be an impediment to optimization if it happened (much) earlier in the planner, but for the situation at hand the only code that's going to be looking at the tree is the executor and maybe ruleutils, both of which are much too stupid to be bothered by such aliasing. > This makes me wonder if we need > some kind of scheme for saving and restoring affected params whenever > Gather switches between executing the plan directly and emitting > tuples from workers, or something like that... I don't think we need to (or should) go there if this is the only problem. What's worrying me is what other assumptions based on serial plan execution are getting broken by injecting Gather into mid levels of a plan tree. regards, tom lane