Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
От | Alvaro Herrera |
---|---|
Тема | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Дата | |
Msg-id | 20210420224107.GA11029@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
|
Список | pgsql-hackers |
OK so after mulling this over for a long time, here's a patch for this. It solves the problem by making the partition descriptor no longer be cached if a detached partition is omitted. Any transaction that needs a partition descriptor that excludes detached partitions, will have to recreate the partdesc from scratch. To support this, I changed the output boolean semantics: instead of "does this partdesc include an detached partitions" as in your patch, it now is "are there any detached partitions". But whenever no detached partitions exist, or when all partitions including detached are requested, then the cached descriptor is returned (because that necessarily has to be correct). The main difference this has to your patch is that we always keep the descriptor in the cache and don't rebuild anything, unless a detached partition is present. I flipped the find_inheritance_children() input boolean, from "include_detached" to "omit_detached". This is more natural, given the internal behavior. You could argue to propagate that naming change to the partdesc.h API and PartitionDirectory, but I don't think there's a need for that. I ran all the detach-partition-concurrently tests under debug_invalidate_system_caches_always=1 and everything passes. I experimented with keeping a separate cached partition descriptor that omits the detached partition, but that brings back some trouble; I couldn't find a way to invalidate such a cached entry in a reasonable way. I have the patch for that, if somebody wants to play with it. -- Álvaro Herrera Valdivia, Chile "That sort of implies that there are Emacs keystrokes which aren't obscure. I've been using it daily for 2 years now and have yet to discover any key sequence which makes any sense." (Paul Thomas)
Вложения
В списке pgsql-hackers по дате отправления: