Re: ALTER TABLE DETACH PARTITION violates serializability

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER TABLE DETACH PARTITION violates serializability
Дата
Msg-id 1861436.1636759306@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER TABLE DETACH PARTITION violates serializability  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: ALTER TABLE DETACH PARTITION violates serializability  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I understand that the behavior is not fully correct, but given the way
> most people are going to use this (which is that they're no longer
> terribly interested in the data of the partition being detached/dropped)
> and the severity of the penalties if we implement a full solution, I
> lean towards documenting it rather than fixing it.

> Another option might be to play with the trade-offs in the CONCURRENTLY
> mode vs. the regular one.  If we make the CONCURRENTLY mode wait for all
> snapshots, we would only be making worse a mode that's already
> documented to potentially take a long time.  So people who want safety
> can use that mode, and the others are aware of the risk.

Meh ... "wrong by default" doesn't seem like it fits the Postgres ethos.
How about adding an option UNSAFE (orthogonal to CONCURRENTLY) that
activates the current behavior, and without it we wait for everything?

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: support for MERGE
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Should AT TIME ZONE be volatile?