Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Tender Wang <tndrwang@gmail.com>
From: tender wang <tndrwang@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-08-04T10:10:53Z
Lists: pgsql-hackers
Oversight the DetachPartitionFinalize() again, I found the root cause why 'r_p_id_fkey' wat not removed. DetachPartitionFinalize() call the GetParentedForeignKeyRefs() func to get tuple from pg_constraint that will be delete but failed. according to the comments, the GetParentedForeignKeyRefs() func get the tuple reference me not I reference others. I try to fix this bug : i. ConstraintSetParentConstraint() should not be called in DetachPartitionFinalize(), because after conparentid was set to 0, we can not find inherited foreign keys. ii. create another function like GetParentedForeignKeyRefs(), but the ScanKey should be conrelid field not confrelid. I quickly test on my above solution in my env, can be solve above issue. tender wang <tndrwang@gmail.com> 于2023年8月4日周五 17:04写道: > Oversight the DetachPartitionFinalize(), I found another bug below: > > postgres=# CREATE TABLE p ( id bigint PRIMARY KEY ) PARTITION BY list (id); > CREATE TABLE > postgres=# CREATE TABLE p_1 PARTITION OF p FOR VALUES IN (1); > CREATE TABLE > postgres=# CREATE TABLE r_1 ( > postgres(# id bigint PRIMARY KEY, > postgres(# p_id bigint NOT NULL > postgres(# ); > CREATE TABLE > postgres=# CREATE TABLE r ( > postgres(# id bigint PRIMARY KEY, > postgres(# p_id bigint NOT NULL, > postgres(# FOREIGN KEY (p_id) REFERENCES p (id) > postgres(# ) PARTITION BY list (id); > CREATE TABLE > postgres=# ALTER TABLE r ATTACH PARTITION r_1 FOR VALUES IN (1); > ALTER TABLE > postgres=# ALTER TABLE r DETACH PARTITION r_1; > ALTER TABLE > postgres=# insert into r_1 values(1,1); > ERROR: insert or update on table "r_1" violates foreign key constraint > "r_p_id_fkey" > DETAIL: Key (p_id)=(1) is not present in table "p". > > After detach operation, r_1 is normal relation and the inherited foreign > key 'r_p_id_fkey' should be removed. > > > tender wang <tndrwang@gmail.com> 于2023年8月3日周四 17:34写道: > >> I think the code to determine that fk of a partition is inherited or not >> is not enough. >> For example, in this case, foreign key r_1_p_id_fkey1 is not inherited >> from parent. >> >> If conform->conparentid(in DetachPartitionFinalize func) is valid, we >> should recheck confrelid(pg_constraint) field. >> >> I try to fix this problem in the attached patch. >> Any thoughts. >> >> Alvaro Herrera <alvherre@alvh.no-ip.org> 于2023年8月3日周四 17:02写道: >> >>> On 2023-Aug-03, tender wang wrote: >>> >>> > I think old "sub-FK" should not be dropped, that will be violates >>> foreign >>> > key constraint. >>> >>> Yeah, I've been playing more with the patch and it is definitely not >>> doing the right things. Just eyeballing the contents of pg_trigger and >>> pg_constraint for partitions added by ALTER...ATTACH shows that the >>> catalog contents are inconsistent with those added by CREATE TABLE >>> PARTITION OF. >>> >>> -- >>> Álvaro Herrera PostgreSQL Developer — >>> https://www.EnterpriseDB.com/ >>> >>
Commits
-
Fix some more bugs in foreign keys connecting partitioned tables
- f7d510a38245 16.5 landed
- 936ab6de9595 17.1 landed
- 2d5fe514052a 18.0 landed
- 1b216fceffe3 15.9 landed
-
Restructure foreign key handling code for ATTACH/DETACH
- d20194cead75 13.17 landed
- 5d83bad6b87d 15.9 landed
- 5914a22f6ea5 17.1 landed
- 53af9491a043 18.0 landed
- 46a8c27a7226 14.14 landed
- 2aaf2a28b87e 16.5 landed
-
Create foreign key triggers in partitioned tables too
- f4566345cf40 15.0 cited