BUG #18628: Race condition during attach/detach partition breaks constraints of partition having foreign key
The following bug has been logged on the website:
Bug reference: 18628
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 17rc1
Operating system: Ubuntu 22.04
Description:
The following script:
for ((i=1;i<=100;i++)); do
psql -q -c "DROP TABLE IF EXISTS pt, p1, p2 CASCADE;"
echo "
CREATE TABLE pt (id int PRIMARY KEY, rid int,
FOREIGN KEY (rid) REFERENCES pt(id))
PARTITION BY LIST (id);
CREATE TABLE p1 PARTITION OF pt FOR VALUES IN (1);
CREATE TABLE p2 (id int PRIMARY KEY, rid int);
" | psql -q
psql -c "ALTER TABLE pt DETACH PARTITION p1;" &
psql -c "ALTER TABLE pt ATTACH PARTITION p1 FOR VALUES IN (1);" &
psql -c "ALTER TABLE pt ATTACH PARTITION p2 FOR VALUES IN (2);"
wait
echo "
ALTER TABLE pt DETACH PARTITION p1;
" | psql 2>&1 | grep 'could not find' && break;
done
psql -c "
SELECT c.conname, c.oid, t.tgname, tgtype
FROM pg_trigger t, pg_constraint c, pg_class cl
WHERE tgconstraint = c.oid AND conrelid = cl.oid AND
cl.relname = 'p1';"
ends up with:
ERROR: could not find ON INSERT check triggers of foreign key constraint
16409
and the p1 constraints at the end are:
conname | oid | tgname | tgtype
-------------+-------+------------------------------+--------
p1_rid_fkey | 16409 | RI_ConstraintTrigger_a_16410 | 9
p1_rid_fkey | 16409 | RI_ConstraintTrigger_a_16411 | 17
pt_rid_fkey | 16399 | RI_ConstraintTrigger_c_16400 | 5
pt_rid_fkey | 16399 | RI_ConstraintTrigger_c_16401 | 17
(4 rows)
Whilst when the partition is in normal conditions, it's constraints are:
conname | oid | tgname | tgtype
-------------+-------+------------------------------+--------
pt_rid_fkey | 19171 | RI_ConstraintTrigger_a_19182 | 9
pt_rid_fkey | 19171 | RI_ConstraintTrigger_a_19183 | 17
pt_rid_fkey | 19171 | RI_ConstraintTrigger_c_19172 | 5
pt_rid_fkey | 19171 | RI_ConstraintTrigger_c_19173 | 17
Reproduced on REL_15_STABLE (starting from 4566345cf) .. master.
22.09.2024 17:00, PG Bug reporting form wrote:
The following script:
...
ends up with:
ERROR: could not find ON INSERT check triggers of foreign key constraint
16409
I'm sorry, I' was too hasty to untangle those queries. Now I see that
this error can be produced with this serial script:
CREATE TABLE pt (id int PRIMARY KEY, rid int,
FOREIGN KEY (rid) REFERENCES pt(id))
PARTITION BY LIST (id);
CREATE TABLE p1 PARTITION OF pt FOR VALUES IN (1);
ALTER TABLE pt DETACH PARTITION p1;
-- p1 gets a constraint:
-- "pt_rid_fkey" FOREIGN KEY (rid) REFERENCES pt(id)
CREATE TABLE p2 PARTITION OF pt FOR VALUES IN (2);
-- CloneFkReferenced() -> addFkRecurseReferenced() clones the above
-- constraint and creates another one:
-- conname: p1_rid_fkey, conrelid: id of p1, confrelid: id of p2,
-- conparentid: id of the above constraint
-- (\d+ p2 doesn't show this constraint due to conparentid != 0)
ALTER TABLE pt ATTACH PARTITION p1 FOR VALUES IN (1);
-- p1 attached with no constraints added or removed
ALTER TABLE pt DETACH PARTITION p1;
-- DetachPartitionFinalize() gets the p1_rid_fkey constraint with
-- RelationGetFKeyList(partRel) and then fails to find INSERT trigger for
-- it, because the constraint has only DELETE and UPDATE triggers linked
-- to the p2 relation.
ERROR: could not find ON INSERT check triggers of foreign key constraint 16410
Alvaro, could you please take a look at this?
Best regards,
Alexander
Alexander Lakhin <exclusion@gmail.com> 于2024年9月24日周二 19:00写道：
22.09.2024 17:00, PG Bug reporting form wrote:
The following script:
...
ends up with:
ERROR: could not find ON INSERT check triggers of foreign key constraint
16409I'm sorry, I' was too hasty to untangle those queries. Now I see that
this error can be produced with this serial script:
CREATE TABLE pt (id int PRIMARY KEY, rid int,
FOREIGN KEY (rid) REFERENCES pt(id))
PARTITION BY LIST (id);CREATE TABLE p1 PARTITION OF pt FOR VALUES IN (1);
ALTER TABLE pt DETACH PARTITION p1;
-- p1 gets a constraint:
-- "pt_rid_fkey" FOREIGN KEY (rid) REFERENCES pt(id)CREATE TABLE p2 PARTITION OF pt FOR VALUES IN (2);
-- CloneFkReferenced() -> addFkRecurseReferenced() clones the above
-- constraint and creates another one:
-- conname: p1_rid_fkey, conrelid: id of p1, confrelid: id of p2,
-- conparentid: id of the above constraint
-- (\d+ p2 doesn't show this constraint due to conparentid != 0)ALTER TABLE pt ATTACH PARTITION p1 FOR VALUES IN (1);
-- p1 attached with no constraints added or removedALTER TABLE pt DETACH PARTITION p1;
-- DetachPartitionFinalize() gets the p1_rid_fkey constraint with
-- RelationGetFKeyList(partRel) and then fails to find INSERT trigger for
-- it, because the constraint has only DELETE and UPDATE triggers linked
-- to the p2 relation.ERROR: could not find ON INSERT check triggers of foreign key constraint
16410Alvaro, could you please take a look at this?
I haven't looked at it in detail, but I have a feeling that this issue has
a very close relation to the issue in [1]/messages/by-id/CAECtzeWHCA+6tTcm2Oh2+g7fURUJpLZb-=pRXgeWJ-Pi+VU=_w@mail.gmail.com.
Now we don't do well when the partition table references itself.
[1]: /messages/by-id/CAECtzeWHCA+6tTcm2Oh2+g7fURUJpLZb-=pRXgeWJ-Pi+VU=_w@mail.gmail.com
/messages/by-id/CAECtzeWHCA+6tTcm2Oh2+g7fURUJpLZb-=pRXgeWJ-Pi+VU=_w@mail.gmail.com
--
Thanks,
Tender Wang
https://www.openpie.com/
On 2024-Sep-24, Alexander Lakhin wrote:
I'm sorry, I' was too hasty to untangle those queries. Now I see that
this error can be produced with this serial script:
[...]
I suspect this is the same problem that was reported by Jehan-Guillaume
de Rorthais, for which there are two patches proposed, his and mine:
[1]: /messages/by-id/202408072250.2c4fkhwf56lk@alvherre.pgsql
[2]: /messages/by-id/20240905005728.0836d609@karst
I haven't looked at his patch, but I suspect it's better than mine on
maintainability grounds. I think his code causes more catalog churn,
though perhaps we don't care too much about that in this particular
case.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
24.09.2024 14:23, Alvaro Herrera wrote:
I suspect this is the same problem that was reported by Jehan-Guillaume
de Rorthais, for which there are two patches proposed, his and mine:[1] /messages/by-id/202408072250.2c4fkhwf56lk@alvherre.pgsql
[2] /messages/by-id/20240905005728.0836d609@karstI haven't looked at his patch, but I suspect it's better than mine on
maintainability grounds. I think his code causes more catalog churn,
though perhaps we don't care too much about that in this particular
Yes, v2-0001-Rework-foreign-key-....patch works for me — the partition
detached with no error.
Sorry for the noise again.
Best regards,
Alexander
Alexander Lakhin <exclusion@gmail.com> 于2024年9月24日周二 20:00写道：
24.09.2024 14:23, Alvaro Herrera wrote:
I suspect this is the same problem that was reported by Jehan-Guillaume
de Rorthais, for which there are two patches proposed, his and mine:[1] /messages/by-id/202408072250.2c4fkhwf56lk@alvherre.pgsql
[2] /messages/by-id/20240905005728.0836d609@karstI haven't looked at his patch, but I suspect it's better than mine on
maintainability grounds. I think his code causes more catalog churn,
though perhaps we don't care too much about that in this particularYes, v2-0001-Rework-foreign-key-....patch works for me — the partition
detached with no error.
The Alvaro's version applied failure on HEAD because the fc0438b4e80 added
an argument to CreateConstraintEntry(). I fixed it. And I tested the patch
using your
providing script. No error again.
--
Thanks,
Tender Wang
https://www.openpie.com/
On Tue, 24 Sep 2024 21:10:48 +0800
Tender Wang <tndrwang@gmail.com> wrote:
Alexander Lakhin <exclusion@gmail.com> 于2024年9月24日周二 20:00写道：
24.09.2024 14:23, Alvaro Herrera wrote:
I suspect this is the same problem that was reported by Jehan-Guillaume
de Rorthais, for which there are two patches proposed, his and mine:[1] /messages/by-id/202408072250.2c4fkhwf56lk@alvherre.pgsql
[2] /messages/by-id/20240905005728.0836d609@karstI haven't looked at his patch, but I suspect it's better than mine on
maintainability grounds. I think his code causes more catalog churn,
though perhaps we don't care too much about that in this particularYes, v2-0001-Rework-foreign-key-....patch works for me — the partition
detached with no error.
I just sent the v3 set of patchs, rebased against head (it was conflicting with
new temporal FK).
See: /messages/by-id/20240925144240.2b579a27@karst
Testing your scenario against current head fails.
Testing your scenario against the v3 set of patchs doesn't show the error.
Regards,