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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Thom Brown <thom(at)linux(dot)com>, 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-03 22:48:18
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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(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?

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-07-03 23:28:40 Re: Deleting prepared statements from libpq.
Previous Message Thomas Munro 2023-07-03 22:41:14 Re: Large files for relations