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  (David Rowley <david.rowley@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [bug fix] Cascaded standby cannot start after a clean shutdown
Следующее
От: David Rowley
Дата:
Сообщение: Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian