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 1utc9h-00B6mQ-29 for pgsql-bugs@arkaria.postgresql.org; Wed, 03 Sep 2025 01:19:21 +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 1utc9e-006Jll-Ka for pgsql-bugs@arkaria.postgresql.org; Wed, 03 Sep 2025 01:19:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1utc9e-006Jlc-C8 for pgsql-bugs@lists.postgresql.org; Wed, 03 Sep 2025 01:19:18 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1utc9d-000FK0-03 for pgsql-bugs@lists.postgresql.org; Wed, 03 Sep 2025 01:19:17 +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 5831JFhb711591; Tue, 2 Sep 2025 21:19:15 -0400 From: Tom Lane To: Richard Guo cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error In-reply-to: References: <19037-3d1c7bb553c7ce84@postgresql.org> <50858.1756590676@sss.pgh.pa.us> <346889.1756738657@sss.pgh.pa.us> <589702.1756826835@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Wed, 03 Sep 2025 09:42:34 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <711589.1756862355.1@sss.pgh.pa.us> Date: Tue, 02 Sep 2025 21:19:15 -0400 Message-ID: <711590.1756862355@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > One thing I'm not quite sure about is whether we should backpatch this > fix to pre-v17 branches. Prior to v17, estimate_array_length() wasn't > taught to use statistics, so this error isn't reproducible there. > OTOH, passing a root without a valid simple_rel_array to > cost_qual_eval() still seems potentially unsafe. What do you think? Yeah, "is there any other instance of this problem?" is the $64 question here. I was initially thinking v17 is sufficient, but the possibility that some extension might be vulnerable makes me lean to back-patching further. Your call ... regards, tom lane