Re: Another FK violation when referencing a multi-level partitioned table
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>,
pgsql-bugs@lists.postgresql.org
Date: 2020-02-09T17:48:49Z
Lists: pgsql-bugs
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > On 2020-Feb-06, Jehan-Guillaume de Rorthais wrote: >> Please, find in attachment a proposal patch to fix this FK violation. > You fix looks correct to me, so pushed. I took a minute to apply some > minor corrections to the comments, too. FWIW, I think the test query is too smart for its own good: SELECT fk.fk_a, pk.a FROM fkpart9.fk LEFT JOIN fkpart9.pk ON fk.fk_a = pk.a WHERE fk.fk_a=35; The trouble with this is that the planner would be fully within its rights to conclude that the FK constraint means a pk row must exist for every fk row, and hence strength-reduce the left join to a plain join. That would mask this bug, if it ever reappeared. There's no such optimization today, but people have proposed patches that do that or very similar things, so I have no confidence in the long-term safety of this test case. I'd replace the above SELECT with just SELECT * FROM fkpart9.fk; and maybe also similarly select all of fkpart9.pk, if you wanted to verify that the right thing had happened on that side. regards, tom lane
Commits
-
Simplify FK-to-partitioned regression test query
- b2304a71748a 13.0 landed
- 3f50d5ced3f8 12.3 landed
-
Fix failure to create FKs correctly in partitions
- 55173d2e663f 13.0 landed
- 2c80a656c2b5 12.2 landed