mirror of
https://github.com/postgres/postgres.git
synced 2026-04-29 02:00:35 -04:00
4e71700584
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.jp
37 lines
1.1 KiB
RPMSpec
37 lines
1.1 KiB
RPMSpec
# 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"
|