Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
От | Amit Langote |
---|---|
Тема | Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian |
Дата | |
Msg-id | 81678336-3f25-45fc-abed-05e5a03ebe27@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
|
Список | 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 по дате отправления: