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