Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Kevin Grittner <kgrittn(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)
Date: 2017-05-18 10:16:40
Message-ID: ed4a97f4-8e8d-949b-724f-d7a86cbf9c69@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/05/18 7:13, Thomas Munro wrote:
> On Wed, May 17, 2017 at 7:42 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> On Wed, May 17, 2017 at 6:04 PM, Amit Langote
>> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> targetRelInfo should instead be set to mtstate->rootResultRelInfo that was
>>> set in ExecInitModifyTable() as described above, IOW, as follows:
>>>
>>> /* Partitioned table. */
>>> if (mtstate->rootResultRelInfo != NULL)
>>> targetRelInfo = mtstate->rootResultRelInfo;
>>
>> Ah, I see. Thank you. Fixed in the attached.
>
> Here's a post-pgindent rebase.

I read through the latest patch. Some comments:

Do we need to update documentation? Perhaps, some clarification on the
inheritance/partitioning behavior somewhere.

+typedef struct TriggerTransitionState
+{
...
+ bool ttf_delete_old_table;

Just curious: why ttf_? TriggerTransition field?

- Assert((enrmd->reliddesc == InvalidOid) != (enrmd->tupdesc == NULL));
+ Assert((enrmd->reliddesc == InvalidOid) !=
+ (enrmd->tupdesc == NULL));

Perhaps, unintentional change?

+ original_tuple = tuple;
map = mtstate->mt_partition_tupconv_maps[leaf_part_index];
if (map)
{
@@ -570,8 +572,17 @@ ExecInsert(ModifyTableState *mtstate,
setLastTid(&(tuple->t_self));
}

+ /*
+ * If we inserted into a partitioned table, then insert routing logic may
+ * have converted the tuple to a partition's format. Make the original
+ * unconverted tuple available for transition tables.
+ */
+ if (mtstate->mt_transition_state != NULL)
+ mtstate->mt_transition_state->original_insert_tuple = original_tuple;

I'm not sure if it's significant for transition tables, but what if a
partition's BR trigger modified the tuple? Would we want to include the
modified version of the tuple in the transition table or the original as
the patch does? Same for the code in CopyFrom().

* 'tup_conv_maps' receives an array of TupleConversionMap objects with one
* entry for every leaf partition (required to convert input tuple based
* on the root table's rowtype to a leaf partition's rowtype after tuple
- * routing is done
+ * routing is done)

Oh, thanks! :)

Other than the above minor nitpicks, patch looks good to me.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-05-18 11:06:48 Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur
Previous Message Marina Polyakova 2017-05-18 09:50:51 Re: WIP Patch: Precalculate stable functions, infrastructure v1