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

On Mon, Jul 03, 2023 at 07:46:27PM +0200, Alvaro Herrera wrote:
> On 2023-Jul-01, Thom Brown wrote:
>> 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.

I could imagine a code path for manual and automatic operations for
REINDEX (?) at table level and at database level, but using this
keyword would be strange, as well. CONCURRENTLY cannot work on system
indexes so SYSTEM does not make sense, and index level is no different
than a DROP.

> Well, I definitely agree that it would be useful to have *something*
> that automatically removes debris (I'm not sure VACUUM is the best place
> to do it. Perhaps we could have autovacuum check for it, and do it
> separately of vacuum proper.)

Being able to reuse some of the worker/launcher parts from autovacuum
could make things easier for a bgworker implementation, perhaps?
--
Michael