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@2ndquadrant.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
