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 1uUrU5-009gqG-Po for pgsql-bugs@arkaria.postgresql.org; Thu, 26 Jun 2025 18:38:05 +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 1uUrU2-00FA2G-Nu for pgsql-bugs@arkaria.postgresql.org; Thu, 26 Jun 2025 18:38:03 +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 1uUrU2-00FA21-Ez for pgsql-bugs@lists.postgresql.org; Thu, 26 Jun 2025 18:38:03 +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.96) (envelope-from ) id 1uUrU0-004Gec-2I for pgsql-bugs@lists.postgresql.org; Thu, 26 Jun 2025 18:38:02 +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 55QIbvAL1487177; Thu, 26 Jun 2025 14:37:57 -0400 From: Tom Lane To: Alexander Lakhin cc: pgsql-bugs@lists.postgresql.org, Richard Guo Subject: Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references In-reply-to: References: <18953-1c9883a9d4afeb30@postgresql.org> <1268645.1749765012@sss.pgh.pa.us> <1499514.1749848324@sss.pgh.pa.us> <527134.1750087495@sss.pgh.pa.us> <835659.1750177751@sss.pgh.pa.us> <837b0dce-b2f3-4811-bccf-f42e8985d6e2@gmail.com> <3040798.1750617116@sss.pgh.pa.us> <3886446.1750703041@sss.pgh.pa.us> Comments: In-reply-to Alexander Lakhin message dated "Tue, 24 Jun 2025 10:00:00 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1487175.1750963077.1@sss.pgh.pa.us> Date: Thu, 26 Jun 2025 14:37:57 -0400 Message-ID: <1487176.1750963077@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alexander Lakhin writes: > I've managed to discover one more anomaly introduced by a16ef313f, that is > not fixed by fix-bug-18953-some-more: Just to note that I am studying this. It looks to me like the issue is that identify_current_nestloop_params() is handing back a PHV with too few nullingrel bits set for the place that we want to put it, as is acknowledged to be possible in its comments. We thought we could get away with that, but in this context setrefs.c will complain. I'm inclined to try to make it set the bits more accurately, rather than further weaken setrefs.c's cross-checks. I'm wondering again whether this isn't a case that is reachable before a16ef313f. Perhaps the have_dangerous_phv check prevented forming plan trees that could have this issue, but it's not real clear why. regards, tom lane