Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dn7XN-0004Ip-Rw for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Aug 2017 18:16:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dn7XN-0000tE-Ep for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Aug 2017 18:16:25 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dn7XL-0000s2-4w; Wed, 30 Aug 2017 18:16:23 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dn7XI-000783-Lf; Wed, 30 Aug 2017 18:16:22 +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 v7UIGEY8018225; Wed, 30 Aug 2017 14:16:14 -0400 From: Tom Lane To: Amit Kapila cc: Robert Haas , Noah Misch , "Adam, Etienne (Nokia-TECH/Issy Les Moulineaux)" , PostgreSQL Bugs , "Duquesne, Pierre (Nokia-TECH/Issy Les Moulineaux)" , pgsql-hackers Subject: Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90 In-reply-to: References: <11673.1502467154@sss.pgh.pa.us> <20170815025243.GA3986579@rfd.leadboat.com> <26053.1502804769@sss.pgh.pa.us> <2941.1502979564@sss.pgh.pa.us> <28782.1502992247@sss.pgh.pa.us> <29467.1502993219@sss.pgh.pa.us> <18650.1502995942@sss.pgh.pa.us> <1105.1503008416@sss.pgh.pa.us> <24667.1503865781@sss.pgh.pa.us> <3924.1503923486@sss.pgh.pa.us> <300.1503959717@sss.pgh.pa.us> <9314.1503973040@sss.pgh.pa.us> <9861.1504024543@sss.pgh.pa.us> Comments: In-reply-to Amit Kapila message dated "Wed, 30 Aug 2017 15:57:55 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18223.1504116974.1@sss.pgh.pa.us> Date: Wed, 30 Aug 2017 14:16:14 -0400 Message-ID: <18224.1504116974@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Amit Kapila writes: > On Tue, Aug 29, 2017 at 10:05 PM, Tom Lane wrote: >> If no objections, I'll do the additional legwork and push. > No objections. Done. Out of curiosity, I pushed just the rescan-param patch to the buildfarm to start with, to see if anything would fall over, and indeed some things did: * prairiedog has shown several instances of a parallel bitmap heap scan test failing with too many rows being retrieved. I think what's happening there is that the leader's ExecReScanBitmapHeapScan call is slow enough to happen that the worker(s) have already retrieved some rows using the old shared state. We'd determined that the equivalent case for a plain seqscan would result in no failure because the workers would think they had nothing to do, but this evidently isn't true for a parallel bitmap scan. * prairiedog and loach have both shown failures with the test case from a2b70c89c, in which the *first* scan produces too many rows and then the later ones are fine. This befuddled me initially, but then I remembered that nodeNestloop.c will unconditionally do an ExecReScan call on its inner plan before the first ExecProcNode call. With the modified code from 7df2c1f8d, this results in the leader's Gather node's top child having a pending rescan on it due to a chgParam bit. That's serviced when we do the first ExecProcNode call on the child, after having started the workers. So that's another way in which a ReScan call can happen in the leader when workers are already running, and if the workers have already scanned some pages then those pages will get scanned again. So I think this is all fixed up by 41b0dd987, but evidently those patches are not nearly as independent as I first thought. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs