Re: ALTER TABLE DETACH PARTITION violates serializability

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: ALTER TABLE DETACH PARTITION violates serializability
Дата
Msg-id 202111131529.ziiteguf4p6t@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: ALTER TABLE DETACH PARTITION violates serializability  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ALTER TABLE DETACH PARTITION violates serializability  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2021-Nov-12, Tom Lane wrote:

> Meh ... "wrong by default" doesn't seem like it fits the Postgres ethos.

I certainly agree with this, yeah.

> How about adding an option UNSAFE (orthogonal to CONCURRENTLY) that
> activates the current behavior, and without it we wait for everything?

Something like that might be the best compromise.  I don't like having
to grab AEL on the parent table (which the non-concurrent version does)
for as long as every old snapshot is gone, so changing the default
behavior without any escape hatch doesn't sound very pallatable.

I think the best behavior is the CONCURRENTLY option with your
additional wait phase -- if only it worked in a transaction block, it
would be perfect.  Users doing DDL as strong as DETACH should be willing
to wait potentially long time for it to finish, but only if it doesn't
disrupt concurrent load involving other partitions.

I don't feel a need to add UNSAFE as an option to CONCURRENTLY, though.
Users are supposed to be already aware that it takes a long time, and it
doesn't block queries using the remaining partitions.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: support for MERGE
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display