Re: [HACKERS] walsender & parallelism - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] walsender & parallelism
Date
Msg-id 20170601040613.j3ww7s5aqhowiqcj@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] walsender & parallelism  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Re: [HACKERS] walsender & parallelism  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism