Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
От | Álvaro Herrera |
---|---|
Тема | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Дата | |
Msg-id | 20210506173208.GA29458@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY (Pavel Luzanov <p.luzanov@postgrespro.ru>) |
Список | pgsql-hackers |
On 2021-May-05, Pavel Luzanov wrote: > Hello, > > I found this in the documentation, section '5.11.3. Partitioning Using > Inheritance'[1]: > "Some operations require a stronger lock when using declarative partitioning > than when using table inheritance. For example, removing a partition from a > partitioned table requires taking an ACCESS EXCLUSIVE lock on the parent > table, whereas a SHARE UPDATE EXCLUSIVE lock is enough in the case of > regular inheritance." > > This point is no longer valid with some restrictions. If the table has a > default partition, then removing a partition still requires taking an ACCESS > EXCLUSIVE lock. Hmm, are there any other operations for which the partitioning command takes a strong lock than the legacy inheritance corresponding command? If there aren't any, then it's okay to delete this paragraph as in the proposed patch. But if there are any, then I think we should change the example to mention that other operation. I'm not sure what's a good way to verify that, though. Also, it remains true that without CONCURRENTLY the DETACH operation takes AEL. I'm not sure it's worth pointing this out in this paragraph. > May be make sense to add some details about DETACH CONCURRENTLY to the > section '5.11.2.2. Partition Maintenance' and completely remove this point? Maybe you're right, though. -- Álvaro Herrera 39°49'30"S 73°17'W "Las mujeres son como hondas: mientras más resistencia tienen, más lejos puedes llegar con ellas" (Jonas Nightingale, Leap of Faith)
В списке pgsql-hackers по дате отправления: