Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?

From: Thom Brown <thom(at)linux(dot)com>
To: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Date: 2023-07-01 16:39:07
Message-ID: CAA-aLv6jncBAp1s_tHuQ0p0cFyJPL4qt-yMv1YCKRUTS2SMApg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 29 Jun 2023, 14:45 Álvaro Herrera, <alvherre(at)alvh(dot)no-ip(dot)org> wrote:

> ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it
> by having a COMPLETE option you can run later in case things got stuck the
> first time around. I suppose we could do something similar, where the
> server automatically does the needful, whatever that is.
>

So there doesn't appear to be provision for deferred activities.

Could, perhaps, the fact that it is an invalid index that has no locks on
it, and is dependent on the table mean it could be removed by a VACUUM?

I just don't like the idea of the user needing to remove broken things.

Thom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2023-07-01 17:31:32 Re: ICU locale validation / canonicalization
Previous Message Noah Misch 2023-07-01 16:25:45 Re: check_strxfrm_bug()