|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Race between SELECT and ALTER TABLE NO INHERIT|
|Views:||Raw Message | Whole Thread | Download mbox|
I had a case of unexpected error caused by ALTER TABLE NO
=# CREATE TABLE p (a int);
=# CREATE TABLE c1 () INHERITS (p);
session A=# BEGIN;
session A=# ALTER TABLE c1 NO INHERIT p;
session B=# EXPLAIN ANALYZE SELECT * FROM p;
session A=# COMMIT;
session B: ERROR: could not find inherited attribute "a" of relation "c1"
This happens at least back to 9.1 to master and doesn't seem to
be a designed behavior.
The cause is that NO INHERIT doesn't take an exlusive lock on the
parent. This allows expand_inherited_rtentry to add the child
relation into appendrel after removal from the inheritance but
I see two ways to fix this.
The first patch adds a recheck of inheritance relationship if the
corresponding attribute is missing in the child in
make_inh_translation_list(). The recheck is a bit complex but it
is not performed unless the sequence above is happen. It checks
duplication of relid (or cycles in inheritance) following
find_all_inheritors (but doing a bit different) but I'm not sure
it is really useful.
The second patch lets ALTER TABLE NO INHERIT to acquire locks on
the parent first.
Since the latter has a larger impact on the current behavior and
we already treat "DROP TABLE child" case in the similar way, I
suppose that the first approach would be preferable.
Any comments or thoughts?
NTT Open Source Software Center
|Next Message||Kyotaro HORIGUCHI||2017-06-26 09:08:45||Re: shift_sjis_2004 related autority files are remaining|
|Previous Message||Victor Drobny||2017-06-26 08:02:36||A mistake in a comment|