On Thu, Apr 15, 2021 at 08:47:26PM +0200, Matthias van de Meent wrote:
> I recently noticed that ATTACH PARTITION also recursively locks the
> default partition with ACCESS EXCLUSIVE mode when its constraints do
> not explicitly exclude the to-be-attached partition, which I couldn't
> find documented (has been there since PG10 I believe).
I'm not sure it's what you're looking for, but maybe you saw:
https://www.postgresql.org/docs/12/sql-altertable.html
|The default partition can't contain any rows that would need to be moved to the
|new partition, and will be scanned to verify that none are present. This scan,
|like the scan of the new partition, can be avoided if an appropriate
|<literal>CHECK</literal> constraint is present.
And since 2a4d96ebb:
|Attaching a partition acquires a SHARE UPDATE EXCLUSIVE lock on the parent table, in addition to ACCESS EXCLUSIVE
lockson the table to be attached and on the default partition (if any).
From your patch:
> + <para>
> + Similarly, if you have a default partition on the parent table, it is
> + recommended to create a <literal>CHECK</literal> constraint that excludes
> + the to be attached partition constraint. Here, too, without the
> + <literal>CHECK</literal> constraint, this table will be scanned to
> + validate that the updated default partition constraints while holding
> + an <literal>ACCESS EXCLUSIVE</literal> lock on the default partition.
> + </para>
The AEL is acquired in any case, right ?
I think whatever we say here needs to be crystal clear that only the scan can
be skipped.
I suggest that maybe the existing paragraph in alter_table.sgml could maybe say
that an exclusive lock is held, maybe like.
|The default partition can't contain any rows that would need to be moved to the
|new partition, and will be scanned to verify that none are present. This scan,
|like the scan of the new partition, can be avoided if an appropriate
|<literal>CHECK</literal> constraint is present.
|The scan of the default partition occurs while it is exclusively locked.
--
Justin
