Re: ATTACH PARTITION locking documentation for DEFAULT partitions - Mailing list pgsql-hackers

From David Rowley
Subject Re: ATTACH PARTITION locking documentation for DEFAULT partitions
Date
Msg-id CAApHDvr7PZmpDjN3Qrgv9YjXNaR0zAo_rLhyeYP1H2vUgwZ2Kw@mail.gmail.com
Whole thread Raw
In response to Re: ATTACH PARTITION locking documentation for DEFAULT partitions  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: ATTACH PARTITION locking documentation for DEFAULT partitions  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
On Tue, 13 Jul 2021 at 02:30, Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> 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.

I had in mind that was implied, but maybe it's better to be explicit about that.

I've adjusted the patch and attached what I came up with. Let me know
what you think.

I think this can be back-patched as far as 12. Before then we took an
AEL on the partitioned table, so it seems much less important since
any concurrency would be blown out by the AEL.

David

Attachment

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Fwd: Emit namespace in post-copy output
Next
From: David Rowley
Date:
Subject: Re: ORDER BY pushdowns seem broken in postgres_fdw