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

From Michael Paquier
Subject Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Date
Msg-id ZKNQMhNFrB1L1zT7@paquier.xyz
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 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@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.

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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Large files for relations
Next
From: Michael Paquier
Date:
Subject: Re: Deleting prepared statements from libpq.