On 2024-Dec-11, Antonin Houska wrote: > Oh, it was too messy. I think I was thinking of too many things at once (such > as locking the old heap, the new heap and the new heap's TOAST). Also, one > thing that might have contributed to the confusion is that make_new_heap() has > the 'lockmode' argument, which receives various values from various > callers. However, both the new heap and its TOAST relation are eventually > created by heap_create_with_catalog(), and this function always leaves the new > relation locked in AccessExclusiveMode. Maybe this needs some refactoring. > > Therefore I reverted the changes arount make_new_heap() and simply pass NoLock > for lockmode in cluster.c
Cool, thanks, I have pushed this. I made some additional minor changes, nothing earth-shattering. Meanwhile the patch 0004 has some seemingly trivial conflicts. If you want to rebase, I'd appreciate that. In the meantime I'll give a look at the next two other API changes. I'm not happy with the idea of having this new command be VACUUM (FULL CONCURRENTLY). It's a bit of an absurd name if you ask me. Heck, even VACUUM (FULL) seems a bit absurd nowadays. Maybe we should have a new toplevel command. Some ideas that have been thrown around: - RETABLE (it's like REINDEX, but for tables) - ALTER TABLE <tab> SQUEEZE - SQUEEZE <table> - VACUUM (SQUEEZE) - VACUUM (COMPACT) - MAINTAIN <tab> COMPACT - MAINTAIN <tab> SQUEEZE -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
