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 1tVjgE-00AyOn-PA for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jan 2025 03:57:59 +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 1tVjgD-00BNzu-WD for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jan 2025 03:57:57 +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 1tVjgD-00BNzm-Nb for pgsql-bugs@lists.postgresql.org; Thu, 09 Jan 2025 03:57:57 +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 1tVjgA-000f9l-0h for pgsql-bugs@lists.postgresql.org; Thu, 09 Jan 2025 03:57:56 +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 5093vivL1793868; Wed, 8 Jan 2025 22:57:44 -0500 From: Tom Lane To: David Rowley cc: Richard Guo , dqetool@126.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18764: server closed the connection unexpectedly In-reply-to: References: <18764-63ad667ea26e877a@postgresql.org> <446342.1735923417@sss.pgh.pa.us> <468120.1735927103@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Thu, 09 Jan 2025 16:44:17 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1793866.1736395064.1@sss.pgh.pa.us> Date: Wed, 08 Jan 2025 22:57:44 -0500 Message-ID: <1793867.1736395064@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Tue, 7 Jan 2025 at 02:14, Richard Guo wrote: >> I've reached the same conclusion. I'm thinking about whether we >> should refrain from pushing pathkeys into the subplan when type >> conversion occurs at the set-operation level. Maybe we can do this >> check in generate_setop_child_grouplist, like below. > So I guess this must mean that we cannot assume that it's ever safe to > assume that a type that is implicitly castable to the top setop's type > sort order matches, so we must ensure we don't generate any > setop_pathkeys for the subquery in this case. The mere fact that there's an implicit cast sure doesn't make it safe. We have implicit casts that cross sort-order behaviors (such as integer to oid), and those would be just as big a hazard as this example where the datatypes aren't physically compatible. We could imagine detecting whether the subquery's datatype belongs to the same btree opfamily as the outer query is using, and if so adapting the pathkeys to that type. But I'm dubious that it's worth the trouble: if this were a common case we'd have discovered this bug sooner. So I'm for just not pushing down the pathkeys if there's a type mismatch. Didn't study the code, so have no opinion right now on the details of how to check that. regards, tom lane