Re: BUG #15425: DETACH/ATTACH PARTITION bug - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #15425: DETACH/ATTACH PARTITION bug
Date
Msg-id 20181011220902.lx5xr4jl5nxl6ved@alvherre.pgsql
Whole thread Raw
In response to Re: BUG #15425: DETACH/ATTACH PARTITION bug  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BUG #15425: DETACH/ATTACH PARTITION bug  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: BUG #15425: DETACH/ATTACH PARTITION bug  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-bugs
Another version.  I realized that attaching a partitioned partition had
further trouble, because the recursion at each step would consider all
FKs instead of only the FKs that had been cloned.  So I had to split out
the recursive step of the cloning.  Now that works fine.

In order to make this work, I made two little change to struct
ForeignKeyCacheInfo: first, the constraint OID was added.  Second, I
made RelationGetFKeyList() return a nonempty list for partitioned
tables, which it didn't before (because of the optimization that
presupposes no triggers means no FKs, which is not true for partitioned
tables).  As far as I can see, this has no effect on how the planner
uses this function.  (This stuff could be done with repeated scans of
pg_constraint, but it seems much simpler this way.)

Michael sent me his test case offlist, and I verified that it works
correctly with this patch.

Unless there are objections, I intend to get this pushed tomorrow.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-bugs by date:

Previous
From: Abhishek Tripathi
Date:
Subject: Want to acquire lock on tables where primary of one table is foreignkey on othere
Next
From: PG Bug reporting form
Date:
Subject: BUG #15427: DROP INDEX did not free up disk space