Feedback-ID: ie3de48e3:Fastmail
Date: Tue, 8 Sep 2026 09:25:25 +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: <ap-3KAqj28ED0TeA@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAN4CZFPP70u6biGiPc_A65sT4X2phZuTrpZ1gLesokueGNXWUQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ap-3KAqj28ED0TeA%40alvherre.pgsql>
Precedence: bulk

Moving thread to -hackers.

On 2026-Aug-31, Zsolt Parragi wrote:

> On Mon, 31 Aug 2026, Christophe Pettus <xof@thebuild.com> wrote:

> > I think your statement has its own answer embedded in it: It's
> > acceptable for REPACK, a brand-new command, to have different
> > behavior in the presence of invalid indexes specifically because it
> > would be a behavior change if we pushed that change to other
> > commands.
> 
> But that's not exactly what happens here: currently REPACK and REPACK
> (CONCURRENTLY) behave differently in the presence of invalid indexes,
> and that is definitely a bug.

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?

Maybe in pg20, barring complaints against this, we can propagate the
same behavior to CLUSTER and VACUUM FULL.  (But that obviously need more
discussion.)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/