Alvaro Herrera writes:
> On 2021-Nov-12, Tom Lane wrote:
>> 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 p
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
On Fri, Nov 12, 2021 at 3:27 PM Tom Lane wrote:
> I wasn't aware of $SUBJECT ... were you?
I wasn't aware of this particular example, but I didn't spend much
time worrying about it, because DDL interleaved with DML generally
isn't serializable anyway. If you issue "SELECT * FROM
some_previously_u
Alvaro Herrera 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
On 2021-Nov-12, Tom Lane wrote:
> I wasn't aware of $SUBJECT ... were you?
Yeah, I remember pointing out that DETACH and DROP and not fully correct
for serializability, but I can't find any thread where I said it in so
many words. At the time I had no ideas on how to fix it; the idea of
waiting
I wasn't aware of $SUBJECT ... were you?
Here's a demonstration:
drop table if exists pk, fk, pk1, pk2;
create table pk (f1 int primary key) partition by list(f1);
create table pk1 partition of pk for values in (1);
create table pk2 partition of pk for values in (2);
insert into pk values(1);
ins
