On Wed, Sep 16, 2015 at 12:10 AM, Thom Brown <thom@xxxxxxxxx> wrote: > On 7 August 2015 at 12:34, Thom Brown <thom@xxxxxxxxx> wrote: >> On 30 July 2015 at 13:35, Rowan Collins <rowan.collins@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
