mirror of https://github.com/postgres/postgres
If a query against an inheritance tree runs concurrently with an ALTER TABLE that's disinheriting one of the tree members, it's possible to get a "could not find inherited attribute" error because after obtaining lock on the removed member, make_inh_translation_list sees that its columns have attinhcount=0 and decides they aren't the columns it's looking for. An ideal fix, perhaps, would avoid including such a just-removed member table in the query at all; but there seems no way to accomplish that without adding expensive catalog rechecks or creating a likelihood of deadlocks. Instead, let's just drop the check on attinhcount. In this way, a query that's included a just-disinherited child will still succeed, which is not a completely unreasonable behavior. This problem has existed for a long time, so back-patch to all supported branches. Also add an isolation test verifying related behaviors. Patch by me; the new isolation test is based on Kyotaro Horiguchi's work. Discussion: https://postgr.es/m/20170626.174612.23936762.horiguchi.kyotaro@lab.ntt.co.jppull/33/head
parent
d3ca1a6c37
commit
55e5eb4d97
@ -0,0 +1,57 @@ |
||||
Parsed test spec with 2 sessions |
||||
|
||||
starting permutation: s1b s1delc1 s2sel s1c s2sel |
||||
step s1b: BEGIN; |
||||
step s1delc1: ALTER TABLE c1 NO INHERIT p; |
||||
step s2sel: SELECT SUM(a) FROM p; <waiting ...> |
||||
step s1c: COMMIT; |
||||
step s2sel: <... completed> |
||||
sum |
||||
|
||||
11 |
||||
step s2sel: SELECT SUM(a) FROM p; |
||||
sum |
||||
|
||||
1 |
||||
|
||||
starting permutation: s1b s1delc1 s1addc2 s2sel s1c s2sel |
||||
step s1b: BEGIN; |
||||
step s1delc1: ALTER TABLE c1 NO INHERIT p; |
||||
step s1addc2: ALTER TABLE c2 INHERIT p; |
||||
step s2sel: SELECT SUM(a) FROM p; <waiting ...> |
||||
step s1c: COMMIT; |
||||
step s2sel: <... completed> |
||||
sum |
||||
|
||||
11 |
||||
step s2sel: SELECT SUM(a) FROM p; |
||||
sum |
||||
|
||||
101 |
||||
|
||||
starting permutation: s1b s1dropc1 s2sel s1c s2sel |
||||
step s1b: BEGIN; |
||||
step s1dropc1: DROP TABLE c1; |
||||
step s2sel: SELECT SUM(a) FROM p; <waiting ...> |
||||
step s1c: COMMIT; |
||||
step s2sel: <... completed> |
||||
sum |
||||
|
||||
1 |
||||
step s2sel: SELECT SUM(a) FROM p; |
||||
sum |
||||
|
||||
1 |
||||
|
||||
starting permutation: s1b s1delc1 s1modc1a s2sel s1c s2sel |
||||
step s1b: BEGIN; |
||||
step s1delc1: ALTER TABLE c1 NO INHERIT p; |
||||
step s1modc1a: ALTER TABLE c1 ALTER COLUMN a TYPE float; |
||||
step s2sel: SELECT SUM(a) FROM p; <waiting ...> |
||||
step s1c: COMMIT; |
||||
step s2sel: <... completed> |
||||
error in steps s1c s2sel: ERROR: attribute "a" of relation "c1" does not match parent's type |
||||
step s2sel: SELECT SUM(a) FROM p; |
||||
sum |
||||
|
||||
1 |
||||
@ -0,0 +1,37 @@ |
||||
# ALTER TABLE - Add and remove inheritance with concurrent reads |
||||
|
||||
setup |
||||
{ |
||||
CREATE TABLE p (a integer); |
||||
INSERT INTO p VALUES(1); |
||||
CREATE TABLE c1 () INHERITS (p); |
||||
INSERT INTO c1 VALUES(10); |
||||
CREATE TABLE c2 (a integer); |
||||
INSERT INTO c2 VALUES(100); |
||||
} |
||||
|
||||
teardown |
||||
{ |
||||
DROP TABLE IF EXISTS c1, c2, p; |
||||
} |
||||
|
||||
session "s1" |
||||
step "s1b" { BEGIN; } |
||||
step "s1delc1" { ALTER TABLE c1 NO INHERIT p; } |
||||
step "s1modc1a" { ALTER TABLE c1 ALTER COLUMN a TYPE float; } |
||||
step "s1addc2" { ALTER TABLE c2 INHERIT p; } |
||||
step "s1dropc1" { DROP TABLE c1; } |
||||
step "s1c" { COMMIT; } |
||||
|
||||
session "s2" |
||||
step "s2sel" { SELECT SUM(a) FROM p; } |
||||
|
||||
# NO INHERIT will not be visible to concurrent select, |
||||
# since we identify children before locking them |
||||
permutation "s1b" "s1delc1" "s2sel" "s1c" "s2sel" |
||||
# adding inheritance likewise is not seen if s1 commits after s2 locks p |
||||
permutation "s1b" "s1delc1" "s1addc2" "s2sel" "s1c" "s2sel" |
||||
# but we do cope with DROP on a child table |
||||
permutation "s1b" "s1dropc1" "s2sel" "s1c" "s2sel" |
||||
# this case currently results in an error; doesn't seem worth preventing |
||||
permutation "s1b" "s1delc1" "s1modc1a" "s2sel" "s1c" "s2sel" |
||||
Loading…
Reference in new issue