Re: walsender & parallelism

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