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 1pL47V-0003i6-FD for pgsql-bugs@arkaria.postgresql.org; Thu, 26 Jan 2023 15:24:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pL46V-0001t0-Oa for pgsql-bugs@arkaria.postgresql.org; Thu, 26 Jan 2023 15:23:55 +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 1pL46V-0001sq-GY for pgsql-bugs@lists.postgresql.org; Thu, 26 Jan 2023 15:23:55 +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 1pL46S-0001qX-3Z for pgsql-bugs@lists.postgresql.org; Thu, 26 Jan 2023 15:23:54 +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 30QFNmeq2957102; Thu, 26 Jan 2023 10:23:49 -0500 From: Tom Lane To: Pete Storer cc: "pgsql-bugs@lists.postgresql.org" Subject: Re: FW: Query execution failure In-reply-to: References: Comments: In-reply-to Pete Storer message dated "Wed, 25 Jan 2023 22:17:07 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2957100.1674746628.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2023 10:23:48 -0500 Message-ID: <2957101.1674746628@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Pete Storer writes: > When trying to run a complex join of eight tables - including 6 foreign = tables - the query runs for a few seconds and then terminates with an erro= r message > ERROR: mergejoin input data is out of order You have not shown us the table definitions, nor an EXPLAIN for the query, but this'd indicate that the sort ordering of one or more tables is not like that of the others. Likely causes of this include * corrupt index, if an indexscan is being used instead of an explicit sort * foreign server has a different idea of the locale's sort details than the local server does (or than some other foreign server, if the query touches more than one) If the join key columns are all numeric then it's almost surely a corrupt index somewhere. But if you are joining on string keys then you are subject to the whims of the locale's sort order, and that is a mess, particularly for non-ASCII data. Not only might it be different on different platforms, but even on the same platform it can change over time (with the effect of making indexes on string columns corrupt). There's some details and advice here: https://wiki.postgresql.org/wiki/Locale_data_changes regards, tom lane