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 1pP8Xn-00076k-Qe for pgsql-bugs@arkaria.postgresql.org; Mon, 06 Feb 2023 20:56:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pP8Xm-0007Sd-2l for pgsql-bugs@arkaria.postgresql.org; Mon, 06 Feb 2023 20:56:54 +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 1pP8Xl-0007SU-QV for pgsql-bugs@lists.postgresql.org; Mon, 06 Feb 2023 20:56:53 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pP8Xj-0005bG-LL for pgsql-bugs@lists.postgresql.org; Mon, 06 Feb 2023 20:56:53 +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 316KumJE2824905; Mon, 6 Feb 2023 15:56:48 -0500 From: Tom Lane To: Richard Guo cc: tharakan@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17773: Assert triggered on analyzejoins.c In-reply-to: References: <17773-a592e6cedbc7bac5@postgresql.org> Comments: In-reply-to Richard Guo message dated "Mon, 06 Feb 2023 14:34:13 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2824903.1675717008.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 06 Feb 2023 15:56:48 -0500 Message-ID: <2824904.1675717008@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > On Mon, Feb 6, 2023 at 1:41 PM PG Bug reporting form > wrote: >> create table txt(); >> SELECT >> FROM pg_catalog.pg_roles AS ref_0 >> RIGHT JOIN txt AS ref_1 ON NULL, >> LATERAL (SELECT >> WHERE ref_0.rolpassword ~>=3D~ ref_0.rolpassword) AS subq_2; > It seems something is wrong about the check on PlaceHolderVars in > outer-join removal codes. When we want to know if a PHV actually > references inner-rel's attributes, we check phinfo->ph_var->phexpr with > pull_varnos. I suspect this is wrong. Shouldn't we check > phinfo->ph_var? No -- that would destroy the entire point of that bit of code, which is that ph_eval_at may include a "dummy" reference to the inner rel that we're hoping to remove. That happens if we made the PHV's ph_eval_at equal to its syntactic scope due to its not containing any Vars. We can still remove the join, as long as it's possible to eval the PHV at the join's outer rel instead. After thinking about this I concluded that the Assert I left behind yesterday is just wrong. If we get down to that part of the code, then we know that it's okay to trim the ph_eval_at values of any such PHVs --- but if one of them is mentioned in a qual clause then the clause_relids will also contain those relids. We have to allow that during join_is_removable and then remove the relids during remove_rel_from_query. It's slightly annoying to lose the cross-checking that those Asserts used to afford: what if the mention in clause_relids didn't come from one of the PHVs we're fixing up? But I don't see any simple way to re-implement that cross-check. Adding a lot of logic to do so would be a bit self-defeating I think; the extra code might have bugs itself. regards, tom lane