Feedback-ID: ie3de48e3:Fastmail
Date: Thu, 10 Sep 2026 11:24:55 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Christophe Pettus <xof@thebuild.com>,
	pgsql-hackers@lists.postgresql.org,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Subject: Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes
Message-ID: <aqJ0Qt-3teW-BhSN@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ih3nxo6vxmekktdf"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ap-3KAqj28ED0TeA@alvherre.pgsql>
Archived-At: 
 <https://www.postgresql.org/message-id/aqJ0Qt-3teW-BhSN%40alvherre.pgsql>
Precedence: bulk


--ih3nxo6vxmekktdf
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On 2026-Sep-08, Álvaro Herrera wrote:

> Yes, but I think the question is in which direction should we fix said
> bug.  My preference is to go for Kyotaro's suggestion: have both REPACK
> and REPACK (CONCURRENTLY) raise an error with an invalid index, asking
> the user to drop it.
> 
> Would anybody oppose that?

Concretely, something like this.  (Hmm, I guess this should be noted in
repack.sgml as well.)

I don't want to touch the behavior of REINDEX, CLUSTER or VACUUM FULL in
pg19 at this stage, much less within the context of an "open item"; we
can discuss that for pg20 afterwards.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"

--ih3nxo6vxmekktdf
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
	filename=0001-Fail-REPACK-in-presence-of-isready-indvalid-indexes.patch