From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Tatsuhito Kasahara" <kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4244: ALTER TABLE ... NO INHERIT problem |
Date: | 2008-06-17 13:28:23 |
Message-ID: | 19666.1213709303@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Tatsuhito Kasahara" <kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp> writes:
> The comment in tablecmds.c says "AccessShareLock is probably enough".
> But it actually needs more strong lock mode ?
> ATExecDropInherit(Relation rel, RangeVar *parent)
> /*
> * AccessShareLock on the parent is probably enough, seeing that DROP
> * TABLE doesn't lock parent tables at all. We need some lock since we'll
> * be inspecting the parent's schema.
> */
> parent_rel = heap_openrv(parent, AccessShareLock);
Well, as the comment points out, things are just as bad if you do
"DROP TABLE c1_tbl" instead of ALTER NO INHERIT.
I'm not sure there is a lot we can do about this. Taking a lock
on the parent table that is strong enough to block a SELECT would
just convert the problem into a deadlock (since a SELECT on the
parent will lock parent before child). Hardly seems like an
improvement.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2008-06-17 13:32:50 | Re: BUG #4243: Idle in transaction |
Previous Message | Tatsuhito Kasahara | 2008-06-17 12:29:41 | BUG #4244: ALTER TABLE ... NO INHERIT problem |