On Wed, Sep 16, 2015 at 12:10 AM, Thom Brown <thom@linux.com> wrote:
> On 7 August 2015 at 12:34, Thom Brown <thom@linux.com> wrote:
>> On 30 July 2015 at 13:35, Rowan Collins <rowan.collins@gmail.com> wrote:
>>> So what I want to understand is what the risk of adding this lock are -
>>> under what circumstances would I expect to see dead locks if I manually
>>> added this lock to my partition maintenance functions?
>> I'm not clear on the problems such a change would present either, but I'm
>> probably overlooking the relevant scenario.
> Has anyone got insight as to what's wrong with exclusively locking a parent
> table to disinherit a child table?
I don't see why that error would occur if concurrently selecting
directly from a "child". I can imagine it occurring if selected from
the parent.
For example, one session performs ALTER TABLE somechild NO INHERIT
parent, then another session trying to select from parent would block
for lock on somechild. Once it gets the lock, it checks if somechild
exists at all for safety (because other session may have dropped it).
What it doesn't check though is whether somechild is still in the list
of children of parent. Having failed to do that, it encounters the
error in question when further along it tries to find parent's
attributes in somechild which are no longer there (remember, other
session just disinherited parent). That perhaps needs some fixing. I
may be missing though.
Thanks,
Amit
