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

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>, pgsql-hackers(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-10 09:24:55
Message-ID: aqJ0Qt-3teW-BhSN@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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"

Attachment Content-Type Size
0001-Fail-REPACK-in-presence-of-isready-indvalid-indexes.patch text/x-diff 6.4 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message mailinglists 2026-09-10 09:47:31 unexpected behaviour generating queryid
Previous Message Andrey Rachitskiy 2026-09-10 07:56:47 Re: BUG #19633: Unexpected results of IN (subquery) with a non-deterministic collation

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-09-10 09:25:23 Re: Review items for EXCEPT TABLE publication
Previous Message Amit Langote 2026-09-10 08:58:04 Re: Revert RI fast-path batching from REL_19_STABLE