Thread: 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

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] https://postgr.es/m/202408072250.2c4fkhwf56lk@alvherre.pgsql
[2] https://postgr.es/m/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] https://postgr.es/m/202408072250.2c4fkhwf56lk@alvherre.pgsql
> [2] https://postgr.es/m/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

Yes, v2-0001-Rework-foreign-key-....patch works for me — the partition
detached with no error.

Sorry for the noise again.

Best regards,
Alexander

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] https://postgr.es/m/202408072250.2c4fkhwf56lk@alvherre.pgsql
> > > [2] https://postgr.es/m/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
> >
> > Yes, 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: https://www.postgresql.org/message-id/20240925144240.2b579a27%40karst

Testing your scenario against current head fails.
Testing your scenario against the v3 set of patchs doesn't show the error.

Regards,