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 1r560z-00Ble9-UI for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Nov 2023 15:16: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 1r560y-008uvb-5a for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Nov 2023 15:16: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 1r560x-008uuL-Su for pgsql-bugs@lists.postgresql.org; Mon, 20 Nov 2023 15:16: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 1r560q-007Rco-Q1 for pgsql-bugs@lists.postgresql.org; Mon, 20 Nov 2023 15:16: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 3AKFGYZv1317057; Mon, 20 Nov 2023 10:16:34 -0500 From: Tom Lane To: =?UTF-8?Q?Filip_Sedl=C3=A1k?= cc: pgsql-bugs@lists.postgresql.org, =?UTF-8?Q?Michal_Danil=C3=A1k?= Subject: Re: B-tree Index corruption In-reply-to: <8cf27c03-941e-4b12-9bdc-06237c0302d4@sedlakovi.org> References: <8cf27c03-941e-4b12-9bdc-06237c0302d4@sedlakovi.org> Comments: In-reply-to =?UTF-8?Q?Filip_Sedl=C3=A1k?= message dated "Mon, 20 Nov 2023 16:08:39 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1317055.1700493394.1@sss.pgh.pa.us> Date: Mon, 20 Nov 2023 10:16:34 -0500 Message-ID: <1317056.1700493394@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =?UTF-8?Q?Filip_Sedl=C3=A1k?= writes: > We're on version 15.3 and I see some index misbehaviour fixed in 15.5 > but nothing on btree over text values. I saw some posts about glibc > upgrade changing collation rules but I don't think it's our case because > we see it with plain ASCII values. Sadly, you're wrong about that; see the example at https://wiki.postgresql.org/wiki/Locale_data_changes#Testing_collation If you did an OS upgrade across a glibc collation change, it's best to assume all your indexes on textual columns are corrupt and REINDEX them. > More importantly, we last upgraded > the major OS version in June but I was able to find a row missing from > the index that was inserted a few weeks ago. It can take awhile before the results of inconsistent sorting order become obvious, but the state of the index will progressively degrade as new entries get inserted into the wrong subtree. regards, tom lane