On Mon, 12 Jul 2021 at 15:28, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Tue, 13 Jul 2021 at 00:14, Matthias van de Meent
> <boekewurm+postgres@gmail.com> wrote:
> > Sorry for the delay. I think that covers the basics of what I was
> > missing in these docs, and although it does not cover the recursive
> > 'if the check is implied by constraints don't lock this partition',
> > I'd say that your suggested patch is good enough. Thanks for looking
> > over this.
>
> Isn't that covered the following?
>
> + <para>
> + Further locks must also be held on all sub-partitions if the table being
> + attached is itself a partitioned table. Likewise if the default
> + partition is itself a partitioned table. The locking of the
> + sub-partitions can be avoided by adding a <literal>CHECK</literal>
> + constraint as described in
> + <xref linkend="ddl-partitioning-declarative-maintenance"/>.
> </para>
The exact behaviour is (c.q. QueuePartitionConstraintValidation in
tablecmds.c:17072), for each partition of this table:
1.) if the existing constraints imply the new constraints: return to .
2.) lock this partition with ACCESS EXCLUSIVE
3.) if this is a partitioned table, for each direct child partition,
execute this algorithm.
The algoritm as described in your patch implies that this recursive
locking is conditional on _only_ the check-constraints of the topmost
partition ("performed whilst holding ... and all of its
sub-partitions, if any"), whereas actually the locking on each
(sub-)partition is determined by the constraints of the hierarchy down
to that child partition. It in actuality, this should not matter much,
but this is a meaningful distinction that I wanted to call out.
Regardless of the distinction between actual locking behaviour and
this documentation, we might not want to document this specific
algorithm, as this algorithm might be changed in future versions, and
the proposed documentation leaves a little wiggleroom in changing the
locking behaviour without needing to update the docs.
Kind regards,
Matthias van de Meent
