Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
To: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Amit Langote <amitlangote09@gmail.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
References: <20201103235606.GA17495@alvherre.pgsql>
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Message-ID: <450eebe2-ca1a-0a7a-0447-6eb67265b82f@postgrespro.ru>
Date: Mon, 30 Nov 2020 18:22:35 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20201103235606.GA17495@alvherre.pgsql>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 04.11.2020 02:56, Alvaro Herrera wrote:
> Here's an updated version of this patch.
>
> Apart from rebasing to current master, I made the following changes:
>
> * On the first transaction (the one that marks the partition as
> detached), the partition is locked with ShareLock rather than
> ShareUpdateExclusiveLock.  This means that DML is not allowed anymore.
> This seems a reasonable restriction to me; surely by the time you're
> detaching the partition you're not inserting data into it anymore.
>
> * In ExecInitPartitionDispatchInfo, the previous version always
> excluded detached partitions.  Now it does include them in isolation
> level repeatable read and higher.  Considering the point above, this
> sounds a bit contradictory: you shouldn't be inserting new tuples in
> partitions being detached.  But if you do, it makes more sense: in RR
> two queries that insert tuples in the same partition would not fail
> mid-transaction.  (In a read-committed transaction, the second query
> does fail, but to me that does not sound surprising.)
>
> * ALTER TABLE .. DETACH PARTITION FINALIZE now waits for concurrent old
> snapshots, as previously discussed. This should ensure that the user
> doesn't just cancel the wait during the second transaction by Ctrl-C and
> run FINALIZE immediately afterwards, which I claimed would bring
> inconsistency.
>
> * Avoid creating the CHECK constraint if an identical one already
> exists.
>
> (Note I do not remove the constraint on ATTACH.  That seems pointless.)
>
> Still to do: test this using the new hook added by 6f0b632f083b.

Status update for a commitfest entry.

The commitfest is nearing the end and this thread is "Waiting on Author".
As far as I see the last message contains a patch. Is there anything 
left to work on or it needs review now? Alvaro, are you planning to 
continue working on it?

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company