Re: Race conditions during parallel worker (unclean) exit

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/20240920183931.f0.nmisch@google.com

--
Sami Imseih
Amazon Web Services (AWS)