Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

The v8 patch has the "broken constraint" problem.

Also, it "fails to avoid" adding duplicate constraints:

Check constraints:
"c" CHECK (i IS NOT NULL AND i > 1 AND i < 2)
"cc" CHECK (i IS NOT NULL AND i >= 1 AND i < 2)
"p1_check" CHECK (true)
"p1_i_check" CHECK (i IS NOT NULL AND i >= 1 AND i < 2)

> diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
> index 5c9f4af1d5..0cb846f408 100644
> --- a/doc/src/sgml/catalogs.sgml
> +++ b/doc/src/sgml/catalogs.sgml
> @@ -4485,6 +4485,16 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
> when using declarative partitioning.
> </para></entry>
> </row>
> +
> + <row>
> + <entry role="catalog_table_entry"><para role="column_definition">
> + <structfield>inhdetachpending</structfield> <type>bool</type>
> + </para>
> + <para>
> + Set to true for a partition that is in the process of being detached;
> + false otherwise.
> + </para></entry>
> + </row>

Remove "Set to" ?
And say <literal>true</literal> and <literal>false</literal>

Probably you'll hate the suggestion, but maybe it should be "pendingdetach".
We already have pg_settings.pending_restart.

> + If <literal>CONCURRENTLY</literal> is specified, this process runs in two
> + transactions in order to avoid blocking other sessions that might be accessing
> + the partitioned table. During the first transaction, a
> + <literal>SHARE UPDATE EXCLUSIVE</literal> lock is taken on both parent table and
> + partition, and its partition is marked detached; at that point, the transaction
> + is committed and all transactions using the partitioned table are waited for.
> + Once all those transactions are gone, the second stage acquires

Instead of "gone", say "have completed" ?

> +/*
> + * MarkInheritDetached
> + *
> + * When a partition is detached from its parent concurrently, we don't
> + * remove the pg_inherits row until a second transaction; as a preparatory
> + * step, this function marks the entry as 'detached', so that other

*pending detached

> + * The strategy for concurrency is to first modify the partition catalog
> + * rows to make it visible to everyone that the partition is detached,

the inherits catalog?

> + /*
> + * In concurrent mode, the partition is locked with share-update-exclusive
> + * in the first transaction. This allows concurrent transactions to be
> + * doing DML to the partition.

> + /*
> + * Check inheritance conditions and either delete the pg_inherits row
> + * (in non-concurrent mode) or just set the inhisdetached flag.

detachpending