From 5c698e8987dbaf1d5079f451f1379abed3725c0c Mon Sep 17 00:00:00 2001 From: Noah Misch Date: Tue, 17 Sep 2024 19:53:11 -0700 Subject: Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com --- src/backend/optimizer/plan/planner.c | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'src/backend/optimizer/plan/planner.c') diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 5da863d85de..17c82b376f4 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -327,6 +327,11 @@ standard_planner(Query *parse, const char *query_string, int cursorOptions, * if we want to allow parallel inserts in general; updates and deletes * have additional problems especially around combo CIDs.) * + * We don't try to use parallel mode unless interruptible. The leader + * expects ProcessInterrupts() calls to reach HandleParallelMessages(). + * Even if we called HandleParallelMessages() another way, starting a + * parallel worker is too delay-prone to be prudent when uncancellable. + * * For now, we don't try to use parallel mode if we're running inside a * parallel worker. We might eventually be able to relax this * restriction, but for now it seems best not to have parallel workers @@ -337,6 +342,7 @@ standard_planner(Query *parse, const char *query_string, int cursorOptions, parse->commandType == CMD_SELECT && !parse->hasModifyingCTE && max_parallel_workers_per_gather > 0 && + INTERRUPTS_CAN_BE_PROCESSED() && !IsParallelWorker()) { /* all the cheap tests pass, so scan the query tree */ -- cgit v1.2.3