Re: Race conditions during parallel worker (unclean) exit

> > > > 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.
> > >
> > > I'm not sure this is worth adjusting the FE/BE protocol. I'd prefer regular
> > > ERROR message (PqMsg_ErrorResponse), but only in some minimalistic form. The
> > > worker would only send the message, w/o doing any error handling itself.
> >
>
> > I was thinking of PqMsg_ParallelAborted because we have precedent already
> > with PqMsg_Progress which was introduced in f1889729dd3a as the 'P' message
> > for parallel index progress reported, but later converted to a macro in
> > a99cc6c6b4b.
>
> I realize now that new message type for communication between background
> worker and the leader backend actually shouldn't need the protocol version to
> be bumped - see commit f1889729dd3a.

Right.

> A new message, e.g. PqMsg_WorkerExit, would contain status code. The worker
> would set zero status code when sending the message at the end of
> ParallelWorkerMain(), and non-zero in ParallelWorkerShutdown(). Does that make
> sense to you?

That does sound logical to me. Maybe PqParallelMsg_WorkerExit to match the new
prefix in 8367b63e2cabb.

So, this also means we can be more precise in the error message. Rather than
"lost connection to parallel worker", we can report something like
"parallel worker exited with exit code <n>" when ProcessParallelMessage()
receives a worker exit message indicating that the worker exited
abnormally.

--
Sami Imseih
Amazon Web Services (AWS)