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

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Thom Brown <thom(at)linux(dot)com>
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-03 17:46:27
Message-ID: 20230703174627.46m7bwrstspwxwvs@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
>
> So there doesn't appear to be provision for deferred activities.

There is not.

> 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?

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.)

On the whole, the reason we don't have such a mechanism AFAIK is that
nobody has presented a credible implementation for it. There was a push
to use UNDO to remove orphan files; if we had that, we could also use it
to implement cleanup of dead indexes and partially-detached partitions.
However, that project crashed and burned a long time ago and has seen no
resurrection as yet.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-07-03 17:54:19 Re: Should heapam_estimate_rel_size consider fillfactor?
Previous Message Andres Freund 2023-07-03 17:43:07 Re: Optionally using a better backtrace library?