From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | 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-20 21:07:10 |
Message-ID: | 20181220210710.276yp67wqb5gf5zt@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-12-20 21:11:47 | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Previous Message | Robert Haas | 2018-12-20 21:05:44 | Re: ATTACH/DETACH PARTITION CONCURRENTLY |