| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(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-08-31 23:08:44 |
| Message-ID: | CAN4CZFPP70u6biGiPc_A65sT4X2phZuTrpZ1gLesokueGNXWUQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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. There's no issue with the non concurrent
REPACK, that behaves like the other commands do. Making REPACK
(CONCURRENTLY) handle indexes the same way as other commands currently
do resolves the difference, and doesn't cause any behavior change for
other commands.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2026-09-01 00:43:00 | Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes |
| Previous Message | Christophe Pettus | 2026-08-31 21:34:23 | Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes |