Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
От | Robert Haas |
---|---|
Тема | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Дата | |
Msg-id | CA+Tgmoac4z96EpzYGjbz7NRN6FFtiVLV8qvXSk5o6F6fHgYP6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Thu, Sep 10, 2020 at 4:54 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Interesting example, thanks. It seems this can be fixed without > breaking anything else by changing the planner so that it includes > detached partitions when we are in a snapshot-isolation transaction. > Indeed, the results from the detach-partition-concurrently-1.spec > isolation test are more satisfying with this change. Hmm, so I think the idea here is that since we're out-waiting plans with the old partition descriptor by waiting for lock release, it's OK for anyone who has a lock to keep using the old partition descriptor as long as they continuously hold the lock. Is that right? I can't think of a hole in that logic, but it's probably worth noting in the comments, in case someone is tempted to change the way that we out-wait plans with the old partition descriptor to some other mechanism. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: