From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Date: | 2021-03-15 23:04:37 |
Message-ID: | 20210315230437.GA20801@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Feb-26, Alvaro Herrera wrote:
> Hmm, but if we take this approach, then we're still vulnerable to the
> problem that somebody can do DETACH CONCURRENTLY and cancel the wait (or
> crash the server), then mess up the state before doing DETACH FINALIZE:
> when they cancel the wait, the lock will be released.
>
> I think the right fix is to disallow any action on a partition which is
> pending detach other than DETACH FINALIZE. (Didn't do that here.)
Here's a fixup patch to do it that way. I tried running the commands
you showed and one of them immediately dies with the new error message;
I can't cause the bogus constraint to show up anymore.
I'll clean this up for a real submission tomorrow.
--
Álvaro Herrera 39°49'30"S 73°17'W
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)
Attachment | Content-Type | Size |
---|---|---|
dont.notpatch | text/plain | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-03-15 23:11:10 | Re: New IndexAM API controlling index vacuum strategies |
Previous Message | Andres Freund | 2021-03-15 22:58:35 | Re: [HACKERS] Custom compression methods |