Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
Date
Msg-id 81678336-3f25-45fc-abed-05e5a03ebe27@lab.ntt.co.jp
Whole thread Raw
In response to Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
List pgsql-hackers
On 2018/06/15 20:41, David Rowley wrote:
> On 15 June 2018 at 20:37, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> select * from partitioned_table_a
>> union all
>> select * from partitioned_table_b
>>
>> The only thing that changes with the patch is that
>> ExecLockNonLeafAppendTables is called *twice* for the two nested Appends
>> corresponding to partitioned_table_a and partitioned_table_b, resp.,
>> instead of just once for the top level Append corresponding to the UNION
>> ALL parent.  In fact, when called for the top level Append,
>> ExecLockNonLeafAppendTables is now a no-op.
> 
> If the top level Append is the UNION ALL one, then there won't be any
> partitioned_rels. If that's what you mean by no-op then, yeah. There
> are no duplicate locks already obtained in the parent with the child
> Append node.

Yeah, that's what I meant to say.  I looked for whether the locks end up
being taken twice, once in the UNION ALL parent's ExecInitAppend and then
again in the individual child Appends' ExecInitAppend, but that they
don't, so the patch is right.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [bug fix] Cascaded standby cannot start after a clean shutdown
Next
From: David Rowley
Date:
Subject: Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian