database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00
Code Activity

Handle self-referencing FKs correctly in partitioned tables

Browse Source 
For self-referencing foreign keys in partitioned tables, we weren't
handling creation of pg_constraint rows during CREATE TABLE PARTITION AS
as well as ALTER TABLE ATTACH PARTITION.  This is an old bug -- mostly,
we broke this in 614a406b4f while trying to fix it (so 12.13, 13.9,
14.6 and 15.0 and up all behave incorrectly).  This commit reverts part
of that with additional fixes for full correctness, and installs more
tests to verify the parts we broke, not just the catalog contents but
also the user-visible behavior.

Backpatch to all live branches.  In branches 13 and 14, commit
46a8c27a72 changed the behavior during DETACH to drop a FK
constraint rather than trying to repair it, because the complete fix of
repairing catalog constraints was problematic due to lack of previous
fixes.  For this reason, the test behavior in those branches is a bit
different.  However, as best as I can tell, the fix works correctly
there.

In release notes we have to recommend that all self-referencing foreign
keys on partitioned tables be recreated if partitions have been created
or attached after the FK was created, keeping in mind that violating
rows might already be present on the referencing side.

Reported-by: Guillaume Lelarge <guillaume@lelarge.info>
Reported-by: Matthew Gabeler-Lee <fastcat@gmail.com>
Reported-by: Luca Vallisa <luca.vallisa@gmail.com>
Discussion: https://postgr.es/m/CAECtzeWHCA+6tTcm2Oh2+g7fURUJpLZb-=pRXgeWJ-Pi+VU=_w@mail.gmail.com
Discussion: https://postgr.es/m/18156-a44bc7096f0683e6@postgresql.org
Discussion: https://postgr.es/m/CAAT=myvsiF-Attja5DcWoUWh21R12R-sfXECY2-3ynt8kaOqjw@mail.gmail.com
This commit is contained in:
Álvaro Herrera
2025-05-02 21:25:50 +02:00
parent fd0af4906c
commit b3a9c536db
4 changed files with 127 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
src/backend/commands/tablecmds.c
View File

@ -9576,15 +9576,15 @@ CloneForeignKeyConstraints(List **wqueue, Relation parentRel,
/* This only works for declarative partitioning */
Assert(parentRel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE);
/*
* First, clone constraints where the parent is on the referencing side.
*/
CloneFkReferencing(wqueue, parentRel, partitionRel);
/*
* Clone constraints for which the parent is on the referenced side.
*/
CloneFkReferenced(parentRel, partitionRel);
/*
* Now clone constraints where the parent is on the referencing side.
*/
CloneFkReferencing(wqueue, parentRel, partitionRel);
}
/*
@ -9595,8 +9595,6 @@ CloneForeignKeyConstraints(List **wqueue, Relation parentRel,
* clone those constraints to the given partition. This is to be called
* when the partition is being created or attached.
*
* This ignores self-referencing FKs; those are handled by CloneFkReferencing.
*
* This recurses to partitions, if the relation being attached is partitioned.
* Recursion is done by calling addFkRecurseReferenced.
*/
@ -9672,17 +9670,6 @@ CloneFkReferenced(Relation parentRel, Relation partitionRel)
continue;
}
/*
* Don't clone self-referencing foreign keys, which can be in the
* partitioned table or in the partition-to-be.
*/
if (constrForm->conrelid == RelationGetRelid(parentRel) ||
constrForm->conrelid == RelationGetRelid(partitionRel))
{
ReleaseSysCache(tuple);
continue;
}
/*
* Because we're only expanding the key space at the referenced side,
* we don't need to prevent any operation in the referencing table, so