Re: FK violation in partitioned table after truncating a referencedpartition
От | Alvaro Herrera |
---|---|
Тема | Re: FK violation in partitioned table after truncating a referencedpartition |
Дата | |
Msg-id | 20200206211238.GA29108@alvherre.pgsql обсуждение исходный текст |
Ответ на | FK violation in partitioned table after truncating a referencedpartition (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>) |
Ответы |
Re: FK violation in partitioned table after truncating a referencedpartition
Re: FK violation in partitioned table after truncating a referencedpartition |
Список | pgsql-bugs |
On 2020-Feb-04, Jehan-Guillaume de Rorthais wrote: > Please, find in attachment a bug fix proposal where a truncate on a > partition cascade to the referencing table and truncate all its > partitions if applicable. > > The patch make sure heap_truncate_find_FKs find all referencing relations, > directly **and indirectly** through their parent table. > > When considering the various way of fixing this, I thought about calling > find_all_inheritors on all relations returned by heap_truncate_find_FKs to add > them to the list or relation to truncate (I have a working patch for this as > well). However, I felt like heap_truncate_find_FKs was the real suspect here > and was responsible to find all referencing relations. Hello, thanks for reporting and patching. I agree that patching heap_truncate_find_FKs is a reasonable way to fix. I propose a slightly different formulation: instead of the loop that you have, we can just use the second loop, and add more parent constraints to the list if any constraint we scan in turn has a parent constraint. So we don't repeat the whole thing, but only that second loop. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-bugs по дате отправления: