Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1foZMR-00028e-7c for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Aug 2018 19:15:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1foZMO-0006OI-Hr for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Aug 2018 19:15:36 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1foZMO-0006OB-Ac for pgsql-hackers@lists.postgresql.org; Sat, 11 Aug 2018 19:15:36 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1foZMK-0005eZ-V6 for pgsql-hackers@postgresql.org; Sat, 11 Aug 2018 19:15:35 +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 w7BJFPfQ005476; Sat, 11 Aug 2018 15:15:25 -0400 From: Tom Lane To: Andreas Seltenreich cc: pgsql-hackers@postgresql.org Subject: Re: [sqlsmith] ERROR: plan should not reference subplan's variable In-reply-to: <87va8g7vq0.fsf@ansel.ydns.eu> References: <87va8g7vq0.fsf@ansel.ydns.eu> Comments: In-reply-to Andreas Seltenreich message dated "Sat, 11 Aug 2018 17:45:43 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5474.1534014925.1@sss.pgh.pa.us> Date: Sat, 11 Aug 2018 15:15:25 -0400 Message-ID: <5475.1534014925@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andreas Seltenreich writes: > sqlsmith caused another internal error while testing REL_11_STABLE at > 1b9d1b08fe. The query below on the regression DB yields "plan should > not reference subplan's variable" for me. Thanks for the report. Seems to be wrong order of operations in inheritance_planner: it shouldn't be appending extra SUBQUERY_RTE copies to a subroot that it's going to use as a parent for later iterations. That results in too many copies of the subqueries and screwed-up RTE numbering in the children. regards, tom lane