Re: Fix BUG #17335: Duplicate result rows in Gather node

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fix BUG #17335: Duplicate result rows in Gather node
Дата
Msg-id 2258970.1643128355@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fix BUG #17335: Duplicate result rows in Gather node  (Yura Sokolov <y.sokolov@postgrespro.ru>)
Ответы Re: Fix BUG #17335: Duplicate result rows in Gather node  (David Rowley <dgrowleyml@gmail.com>)
Re: Fix BUG #17335: Duplicate result rows in Gather node  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Yura Sokolov <y.sokolov@postgrespro.ru> writes:
> В Вт, 25/01/2022 в 21:20 +1300, David Rowley пишет:
>> The reason I didn't think it was worth adding a new test was that no
>> tests were added in the original commit.  Existing tests did cover it,

> Existed tests didn't catched the issue. It is pitty fix is merged
> without test case it fixes.

I share David's skepticism about the value of a test case.  The
failure mode that seems likely to me is some other code path making
the same mistake, which a predetermined test would not catch.

Therefore, what I think could be useful is some very-late-stage
assertion check (probably in createplan.c) verifying that the
child of a Gather is parallel-aware.  Or maybe the condition
needs to be more general than that, but anyway the idea is for
the back end of the planner to verify that we didn't build a
silly plan.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: tushar
Дата:
Сообщение: Re: refactoring basebackup.c
Следующее
От: Alexander Pyhalov
Дата:
Сообщение: Re: Foreign join search stops on the first try