Hi Antonin, > Moreover, the leader, after having seen the worker detached from the tuple > queue (TupleQueueReaderNext) a bit later, starts executor cleanup and, as the > worker does not send signals anymore, it gets stuck in > WaitForParallelWorkersToExit().
There have been reports of leader hangs in parallel waits [1], but the one I found was fixed by not entering parallel mode while interrupts were being held. That said, there may still be a good argument here to make the abnormal-exit path of a parallel worker more explicit, which your "sleep(1)" case demonstrates. > Attached is what might be a fix, but I'm not sure if the Terminate message is > appropriate even if the worker in fact didn't finish with success. Right. I don't think "PqMsg_Terminate" is the right message here. It currently represents normal completion: ``` /* Report success. */ pq_putmessage(PqMsg_Terminate, NULL, 0); ``` It seems cleaner to introduce a separate message for this case, maybe "PqMsg_ParallelAborted", and keep the existing "ERROR: lost connection to parallel worker" message. [1] https://www.postgresql.org/message-id/[email protected] -- Sami Imseih Amazon Web Services (AWS)
