Re: ALTER TABLE DETACH PARTITION violates serializability - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TABLE DETACH PARTITION violates serializability
Date
Msg-id 1861436.1636759306@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TABLE DETACH PARTITION violates serializability  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: ALTER TABLE DETACH PARTITION violates serializability
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: support for MERGE
Next
From: Thomas Munro
Date:
Subject: Re: Should AT TIME ZONE be volatile?