Re: ALTER TABLE DETACH PARTITION violates serializability

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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