Re: lock level for DETACH PARTITION looks sketchy

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>
Subject: Re: lock level for DETACH PARTITION looks sketchy
Date: 2018-12-21 00:59:17
Message-ID: de7ce055-7531-c1df-3a91-3d13e5aa0951@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018/12/21 6:07, Alvaro Herrera wrote:
> On 2018-Dec-20, Robert Haas wrote:
>
>> On Thu, Dec 20, 2018 at 3:58 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>>> I think what prompted the lock to be AccessShareLock for the child rel
>>> in the first place is the fact that ATExecDropInherit() (ALTER TABLE NO
>>> INHERIT) uses AccessShare for the *parent* relation.
>>
>> Seems like apples and oranges,
>
> Yes, but I can understand someone looking at ATExecDropInherit while
> writing ATExecDetachRelation and thinking "ah, I have to grab
> AccessShareLock on the other relation" without stopping to think in what
> direction the parenthood between the rels goes.

That was definitely wrong. Partition's schema changes when it's detached,
whereas a (regular) inheritance parent's doesn't when one of its children
is removed.

>> and also maybe not that safe.
>
> I think it's strange, but I'm not interested in analyzing that at this
> time. Its comment do say that DROP TABLE (of the child, I surmise) does
> not acquire *any* lock on the parent, which is also strange.

Per comments in ATExecDropInherit, the reason we lock parent with
AccessShareLock in the DROP INHERIT case is that RemoveInheritance
inspects parent's schema to see which of the child's columns to mark as
having one less parent. DROP TABLE child doesn't need to do that as you
can obviously imagine why.

Thank you both for working on this.

Thanks,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-12-21 01:05:45 Re: A few new options for vacuumdb
Previous Message David Rowley 2018-12-21 00:25:31 Re: Tid scan improvements