Re: [HACKERS] UPDATE of partition key

On Fri, Nov 10, 2017 at 4:42 PM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> Attached is v23 patch that has just the above changes (and also
> rebased on hash-partitioning changes, like update.sql). I am still
> doing some sanity testing on this, although regression passes.

The test coverage[1] is 96.62%. Nice work. Here are the bits that
aren't covered:

In partition.c's pull_child_partition_columns(), the following loop is
never run:

+ foreach(lc, partexprs)
+ {
+ Node *expr = (Node *) lfirst(lc);
+
+ pull_varattnos(expr, 1, &child_keycols);
+ }

In nodeModifyTable.c, the following conditional branches are never run:

if (mtstate->mt_oc_transition_capture != NULL)
+ {
+ Assert(mtstate->mt_is_tupconv_perpart == true);
mtstate->mt_oc_transition_capture->tcs_map =
-
mtstate->mt_transition_tupconv_maps[leaf_part_index];
+
mtstate->mt_childparent_tupconv_maps[leaf_part_index];
+ }

if (node->mt_oc_transition_capture != NULL)
{
-
Assert(node->mt_transition_tupconv_maps != NULL);

node->mt_oc_transition_capture->tcs_map =
-
node->mt_transition_tupconv_maps[node->mt_whichplan];
+
tupconv_map_for_subplan(node, node->mt_whichplan);
}

Is there any reason we shouldn't be able to test these paths?

[1] https://codecov.io/gh/postgresql-cfbot/postgresql/commit/a3beb8d8f598a64d75aa4b3afc143a5d3e3f7826

--
Thomas Munro
http://www.enterprisedb.com