Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1poQPI-00013P-MD for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Apr 2023 15:04:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1poQPH-0000aG-9L for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Apr 2023 15:04:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1poQPH-0000a5-04 for pgsql-hackers@lists.postgresql.org; Mon, 17 Apr 2023 15:04:39 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1poQPE-003Ruh-8B for pgsql-hackers@lists.postgresql.org; Mon, 17 Apr 2023 15:04:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 33HF4XxG2425968; Mon, 17 Apr 2023 11:04:33 -0400 From: Tom Lane To: Richard Guo cc: pgsql-hackers@lists.postgresql.org Subject: Re: Allowing parallel-safe initplans In-reply-to: References: <1129530.1681317832@sss.pgh.pa.us> <1315906.1681394451@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Mon, 17 Apr 2023 15:26:46 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2425966.1681743873.1@sss.pgh.pa.us> Date: Mon, 17 Apr 2023 11:04:33 -0400 Message-ID: <2425967.1681743873@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > So now it seems that the breakage of regression tests is more severe > than being cosmetic. I wonder if we need to update the comments to > indicate the potential wrong results issue if we move the initPlans to > the Gather node. I wondered about that too, but how come neither of us saw non-cosmetic failures (ie, actual query output changes not just EXPLAIN changes) when we tried this? Maybe the case is somehow not exercised, but if so I'm more worried about adding regression tests than comments. I think actually that it does work beyond the EXPLAIN weirdness, because since e89a71fb4 the Gather machinery knows how to transmit the values of Params listed in Gather.initParam to workers, and that is filled in setrefs.c in a way that looks like it'd work regardless of whether the Gather appeared organically or was stuck on by the debug_parallel_query hackery. I've not tried to verify that directly though. regards, tom lane