Re: [HACKERS] walsender & parallelism

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] walsender & parallelism
Дата
Msg-id 20170601040613.j3ww7s5aqhowiqcj@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] walsender & parallelism  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Re: [HACKERS] walsender & parallelism  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On 2017-05-31 23:51:08 -0400, Peter Eisentraut wrote:
> I think the easiest and safest thing to do now is to just prevent
> parallel plans in the walsender.  See attached patch.  This prevents the
> hang in the select_parallel tests run under your new test setup.

I'm not quite sure I can buy this.  The lack of wired up signals has
more problems than just hurting parallelism.  In fact, the USR1 thing
seems like something that we actually should backpatch, rather than
defer to v11.  I think there's some fair arguments to be made that we
shouldn't do the refactoring right now - although I'm not sure about it
- but just not fixing the bugs seems like a bad plan.


> @@ -272,6 +273,7 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
>       */
>      if ((cursorOptions & CURSOR_OPT_PARALLEL_OK) != 0 &&
>          IsUnderPostmaster &&
> +        !am_walsender &&
>          dynamic_shared_memory_type != DSM_IMPL_NONE &&
>          parse->commandType == CMD_SELECT &&
>          !parse->hasModifyingCTE &&

If we were to go for this, surely this'd need a comment.

- Andres



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism