Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes

From: Christophe Pettus <xof(at)thebuild(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes
Date: 2026-09-01 00:43:00
Message-ID: B7375177-D291-4788-9446-965341149948@thebuild.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On Aug 31, 2026, at 16:08, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> On Mon, 31 Aug 2026, Christophe Pettus <xof(at)thebuild(dot)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.

"Differently" as such isn't a bug. "Incorrectly" would be. If REPACK AND REPACK CONCURRENTLY simply refused to run on a table with invalid indexes, that's minimally intrusive and fixes the bug. I agree that the ideal situation is that they work tables with invalid indexes, but I don't consider it a bug if they just refused to.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Fujii Masao 2026-09-01 02:46:06 Re: to_char() on integer with V format silently wraps on overflow
Previous Message PG Bug reporting form 2026-08-31 23:10:00 BUG #19648: Docs on DISTINCT ON do not describe how expressions are matched to ORDER BY