From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: FK violation in partitioned table after truncating a referenced partition |
Date: | 2020-02-07 22:03:14 |
Message-ID: | 20200207230314.350a59bc@firost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, 7 Feb 2020 17:19:48 -0300
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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,
From | Date | Subject | |
---|---|---|---|
Next Message | Jehan-Guillaume de Rorthais | 2020-02-07 22:26:32 | Re: Another FK violation when referencing a multi-level partitioned table |
Previous Message | Tom Lane | 2020-02-07 22:00:51 | Re: BUG #16250: As the owner of a database, I can't CREATE EXTENSION postgis; |