Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take) - Mailing list pgsql-hackers

On Wed, May 17, 2017 at 7:42 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, May 17, 2017 at 6:04 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.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.

Also, I discovered a preexisting bug that is independent of all this
inheritance stuff.  COPY in the batch optimisation case was failing to
capture transition tuples.  I thought about sending a separate patch
but this patch already has a regression test that covers it so I've
included it here.  It's this hunk:

@@ -2872,7 +2872,8 @@ CopyFromInsertBatch(CopyState cstate, EState
*estate, CommandId mycid,
         * anyway.
         */
        else if (resultRelInfo->ri_TrigDesc != NULL &&
-                        resultRelInfo->ri_TrigDesc->trig_insert_after_row)
+                        (resultRelInfo->ri_TrigDesc->trig_insert_after_row ||
+                         resultRelInfo->ri_TrigDesc->trig_insert_new_table))
        {
                for (i = 0; i < nBufferedTuples; i++)
                {

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers