Re: Delay locking partitions during INSERT and UPDATE

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Feb 18, 2019 at 6:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm inclined to think that if we already have lock on the parent
>> partitioned table (thereby, IIUC, guaranteeing that its partitioning
>> info can't change) that the order in which we acquire the same lock
>> level on its partition(s) isn't very important.

> But that being said, I don't think I quite see how the two things you
> mention here are connected to each other. If operation A locks
> parents before children, and operation B also locks parents before
> children, they generally won't deadlock against each other, even if
> each locks the children in a different order.

Right, that's the same thing I was trying to say.

> ... So my question is - what do
> you mean by the parenthetical note about the partitioning info not
> changing? Regardless of whether it does or does not, I think the same
> property holds.

What I was wondering about was the possibility of the set of
tables-that-need-to-be-locked-at-all changing. Maybe that won't
create an issue either, but I'm not quite sure. I do have to say
that I find the idea of somebody changing the partitioning data
concurrently with queries on that partitioned table to be stone
cold petrifying. I don't think I believe you can make that work.

regards, tom lane