@@ -291,13 +291,21 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
291291}
292292
293293/*
294- * glob->parallelModeNeeded should tell us whether it's necessary to
295- * impose the parallel mode restrictions, but we don't actually want to
296- * impose them unless we choose a parallel plan, so it is normally set
297- * only if a parallel plan is chosen (see create_gather_plan). That way,
298- * people who mislabel their functions but don't use parallelism anyway
299- * aren't harmed. But when force_parallel_mode is set, we enable the
300- * restrictions whenever possible for testing purposes.
294+ * glob->parallelModeNeeded is normally set to false here and changed to
295+ * true during plan creation if a Gather or Gather Merge plan is actually
296+ * created (cf. create_gather_plan, create_gather_merge_plan).
297+ *
298+ * However, if force_parallel_mode = on or force_parallel_mode = regress,
299+ * then we impose parallel mode whenever it's safe to do so, even if the
300+ * final plan doesn't use parallelism. It's not safe to do so if the
301+ * query contains anything parallel-unsafe; parallelModeOK will be false
302+ * in that case. Note that parallelModeOK can't change after this point.
303+ * Otherwise, everything in the query is either parallel-safe or
304+ * parallel-restricted, and in either case it should be OK to impose
305+ * parallel-mode restrictions. If that ends up breaking something, then
306+ * either some function the user included in the query is incorrectly
307+ * labelled as parallel-safe or parallel-restricted when in reality it's
308+ * parallel-unsafe, or else the query planner itself has a bug.
301309 */
302310glob -> parallelModeNeeded = glob -> parallelModeOK &&
303311(force_parallel_mode != FORCE_PARALLEL_OFF );