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 1nu40S-0004Me-EA for pgsql-bugs@arkaria.postgresql.org; Thu, 26 May 2022 03:17:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nu40Q-0001AS-VL for pgsql-bugs@arkaria.postgresql.org; Thu, 26 May 2022 03:17:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nu40Q-00019x-NE for pgsql-bugs@lists.postgresql.org; Thu, 26 May 2022 03:17:46 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nu40N-0006MF-Lc for pgsql-bugs@lists.postgresql.org; Thu, 26 May 2022 03:17:45 +0000 Received: from bruce by momjian.us with local (Exim 4.94.2) (envelope-from ) id 1nu40D-00BW5D-Ve; Wed, 25 May 2022 23:17:33 -0400 Date: Wed, 25 May 2022 23:17:33 -0400 From: Bruce Momjian To: Peter Geoghegan Cc: Robert Haas , Alvaro Herrera , Andres Freund , Andrey Borodin , Michael Paquier , =?utf-8?B?0J/QtdGC0YrRgCDQodC70LDQstC+0LI=?= , PostgreSQL mailing lists Subject: Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY Message-ID: References: <202205251643.2py5jjpaw7wy@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, May 25, 2022 at 10:32:43AM -0700, Peter Geoghegan wrote: > On Wed, May 25, 2022 at 10:18 AM Robert Haas wrote: > > Right, I mean I'm not saying I *like* reverting, and I'm not disputing > > it's a good feature. Just that, if we have to choose between this > > feature and not having index corruption, we better not have index > > corruption.... and I'm not seeing any way that we can just tweak this > > and make it work. > > Are we any closer to deciding on a timeline, in light of recent discussion? > > I'm now convinced that an out-of-schedule release is probably the way > to go. My thinking is: are we really going to make users wait for > August 11th for a fix? No, we are unlikely to wait until August. What do we currently know? * Caused by CREATE/REINDEX CONCURRENTLY * No way to detect which indexes were created concurrently * amcheck will be required to find corrupt indexes (options?) * Heap is fine, only index is corrupt * Bug since PG 14 * Not known why reports are only appearing now * Feature will likely need to be removed rather than fixed -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson