Re: ATTACH PARTITION locking documentation for DEFAULT partitions

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема Re: ATTACH PARTITION locking documentation for DEFAULT partitions
Дата
Msg-id CAEze2WjOL-J=+0NWvkvPLEPzNG=32_+2BA+iHtfTqyBjjRgp-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ATTACH PARTITION locking documentation for DEFAULT partitions  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: ATTACH PARTITION locking documentation for DEFAULT partitions
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ronan Dunklau
Дата:
Сообщение: Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Column Filtering in Logical Replication