Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Clean up side-effects of commits ab5fcf2b0 et al.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 7 Apr 2019 16:54:22 +0000 (12:54 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 7 Apr 2019 16:54:22 +0000 (12:54 -0400)
Before those commits, partitioning-related code in the executor could
assume that ModifyTableState.resultRelInfo[] contains only leaf partitions.
However, now a fully-pruned update results in a dummy ModifyTable that
references the root partitioned table, and that breaks some stuff.

In v11, this led to an assertion or core dump in the tuple routing code.
Fix by disabling tuple routing, since we don't need that anyway.
(I chose to do that in HEAD as well for safety, even though the problem
doesn't manifest in HEAD as it stands.)

In v10, this confused ExecInitModifyTable's decision about whether it
needed to close the root table.  But we can get rid of that altogether
by being smarter about where to find the root table.

Note that since the referenced commits haven't shipped yet, this
isn't fixing any bug the field has seen.

Amit Langote, per a report from me

Discussion: https://postgr.es/m/20710.1554582479@sss.pgh.pa.us

src/backend/optimizer/plan/planner.c
src/test/regress/expected/inherit.out
src/test/regress/sql/inherit.sql

index cbd3fb8e0ea1eb3369e364bf4f14856b16cd7f81..5ed691c2e32d1859ba9bb7e399d64678bbb0cc88 100644 (file)
@@ -1732,6 +1732,8 @@ inheritance_planner(PlannerInfo *root)
            withCheckOptionLists = list_make1(parse->withCheckOptions);
        if (parse->returningList)
            returningLists = list_make1(parse->returningList);
+       /* Disable tuple routing, too, just to be safe */
+       root->partColsUpdated = false;
    }
    else
    {
index 4725a159487e6273712d0dc44926aa5d68849531..c6abcfc3cb1065c8940c8a10ed865ca93f4c5e10 100644 (file)
@@ -665,6 +665,15 @@ select tableoid::regclass::text as relname, parted_tab.* from parted_tab order b
  parted_tab_part3 | 3 | a
 (3 rows)
 
+-- modifies partition key, but no rows will actually be updated
+explain update parted_tab set a = 2 where false;
+                       QUERY PLAN                       
+--------------------------------------------------------
+ Update on parted_tab  (cost=0.00..0.00 rows=0 width=0)
+   ->  Result  (cost=0.00..0.00 rows=0 width=0)
+         One-Time Filter: false
+(3 rows)
+
 drop table parted_tab;
 -- Check UPDATE with multi-level partitioned inherited target
 create table mlparted_tab (a int, b char, c text) partition by list (a);
index e91f61bc377737a904139089884a4b1b287b3e48..ae4358588c374b9a85b673e640f7eb36d9d084e0 100644 (file)
@@ -168,6 +168,9 @@ from
 where parted_tab.a = ss.a;
 select tableoid::regclass::text as relname, parted_tab.* from parted_tab order by 1,2;
 
+-- modifies partition key, but no rows will actually be updated
+explain update parted_tab set a = 2 where false;
+
 drop table parted_tab;
 
 -- Check UPDATE with multi-level partitioned inherited target