|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Delay locking partitions during INSERT and UPDATE|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|Next Message||Andres Freund||2019-02-20 16:03:54||Re: Conflict handling for COPY FROM|
|Previous Message||David G. Johnston||2019-02-20 15:59:28||Re: list append syntax for postgresql.conf|