Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rNytB-0006eI-1v for pgsql-bugs@arkaria.postgresql.org; Thu, 11 Jan 2024 17:30:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rNytA-00DjRf-3G for pgsql-bugs@arkaria.postgresql.org; Thu, 11 Jan 2024 17:30:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rNyt9-00DjRW-RQ for pgsql-bugs@lists.postgresql.org; Thu, 11 Jan 2024 17:30:43 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rNyt7-0013BZ-CT for pgsql-bugs@lists.postgresql.org; Thu, 11 Jan 2024 17:30:43 +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 40BHUdRT229609; Thu, 11 Jan 2024 12:30:39 -0500 From: Tom Lane To: holger.reise@vitagroup.ag cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18284: Filter in left lateral join not respected In-reply-to: <74950.1704988899@sss.pgh.pa.us> References: <18284-47505a20c23647f8@postgresql.org> <74950.1704988899@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 11 Jan 2024 11:01:39 -0500" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <229566.1704994216.0@sss.pgh.pa.us> Date: Thu, 11 Jan 2024 12:30:39 -0500 Message-ID: <229608.1704994239@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <229566.1704994216.1@sss.pgh.pa.us> I wrote: > Hmph ... this has been broken for a good long while. Bisecting > shows it gave the right answer before > commit 4be058fe9ec5e630239b656af21fc083371f30ed > so I'm betting that missed a condition about when it is safe to > flatten RTE_RESULT RTEs. Will look, thanks for the report! Huh. It looks like the oversight is actually even more ancient than that, dating clear back to 9e7e29c75 of 2013-08-17. That commit recognized that lateral-reference Vars had to be wrapped in PlaceHolderVars during subquery pullup, but failed to make the same conclusion for PlaceHolderVars. Somehow that didn't cause any visible problems before 4be058fe9, or more likely we just didn't get any relevant trouble reports. This seems to be quite a rare situation: spot testing says that we never reach this code for a PHV with target_rte->lateral true in any of our regression tests. The attached seems to be enough to fix it, though of course it needs a regression test. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="fix-PHV-wrap-rules-for-lateral-references.patch"; charset="us-ascii" Content-ID: <229566.1704994216.2@sss.pgh.pa.us> Content-Description: fix-PHV-wrap-rules-for-lateral-references.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optim= izer/prep/prepjointree.c index d0df5374ef..aa83dd3636 100644 --- a/src/backend/optimizer/prep/prepjointree.c +++ b/src/backend/optimizer/prep/prepjointree.c @@ -2435,8 +2435,13 @@ pullup_replace_vars_callback(Var *var, else if (newnode && IsA(newnode, PlaceHolderVar) && ((PlaceHolderVar *) newnode)->phlevelsup =3D=3D 0) { - /* No need to wrap a PlaceHolderVar with another one, either */ - wrap =3D false; + /* The same rules apply for a PlaceHolderVar */ + if (rcon->target_rte->lateral && + !bms_is_subset(((PlaceHolderVar *) newnode)->phrels, + rcon->relids)) + wrap =3D true; + else + wrap =3D false; } else { ------- =_aaaaaaaaaa0--