Re: FK violation in partitioned table after truncating a referenced partition
Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2020-02-07T22:03:14Z
Lists: pgsql-bugs
On Fri, 7 Feb 2020 17:19:48 -0300 Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > There's another key point I forgot -- which is that we only need to > search for constraints on the topmost partitioned table, not each of its > partitions. The reason is that pg_constraint rows exist on the other > side that reference that relation, for each partition on the other side. Yes, I figured this as well when drawing things during debug time. By this time, I kept it this way because I wasn't sure about potential complications with sub-partitioning and FK to sub-partition only. > So we can do this: [...] > that is, keep appending to the parent_cons list, and not touch the oids > list, until we get to the top of the hierarchy. Then when we redo the > first loop, we'll get all partitions on the other side because they all > have pg_constraint rows that reference the topmost rel. (That is to > say, all the intermediate-partition OIDs should be useless in the 'oids' > list anyway.) It makes the oids list smaller (depending on the partitioning depth). As it is scanned for each FK in pg_constraint, it surely squeeze some more time. I'll stick around irw the other FK violation thread. Please, keep me in the loop. Thank you for the discussion and commit. Regards,
Commits
-
Fix TRUNCATE .. CASCADE on partitions
- ce054a8cd4f4 12.2 landed
- 9710d3d4a87f 13.0 landed