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

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

Previous
From: Alvaro Herrera
Date:
Subject: Re: support for MERGE
Next
From: Alvaro Herrera
Date:
Subject: Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display