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, <alvhe...@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
signature.asc
Description: PGP signature
