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

From David Rowley
Subject Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
Date
Msg-id CAKJS1f-a8EqKAcP0emxRnz4=2OP_DLTH7GizjLzBWwg4xtzuPw@mail.gmail.com
Whole thread Raw
In response to Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
List pgsql-hackers
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.


-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: Jsonb transform for pl/python
Next
From: Alexander Korotkov
Date:
Subject: Re: Jsonb transform for pl/python