Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
| От | David Rowley |
|---|---|
| Тема | Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian |
| Дата | |
| Msg-id | CAKJS1f-a8EqKAcP0emxRnz4=2OP_DLTH7GizjLzBWwg4xtzuPw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Ответы |
Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
|
| Список | 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 по дате отправления: