Re: Does a cancelled REINDEX CONCURRENTLY need to be messy? - Mailing list pgsql-hackers

From Thom Brown
Subject Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Date
Msg-id CAA-aLv6jncBAp1s_tHuQ0p0cFyJPL4qt-yMv1YCKRUTS2SMApg@mail.gmail.com
Whole thread Raw
In response to Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
List pgsql-hackers
On Thu, 29 Jun 2023, 14:45 Álvaro Herrera, <alvherre@alvh.no-ip.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

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: check_strxfrm_bug()
Next
From: Noah Misch
Date:
Subject: Re: ICU locale validation / canonicalization