On Wed, Jan 21, 2015 at 6:35 PM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> On Wed, Jan 21, 2015 at 2:11 AM, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> > On Tue, Jan 20, 2015 at 9:52 PM, Robert Haas <
robertmhaas@gmail.com> wrote:
> >> On Tue, Jan 20, 2015 at 9:41 AM, Amit Kapila <
amit.kapila16@gmail.com>
> >> wrote:
> >> > It seems [WaitForBackgroundWorkerShutdown] has possibility to wait
> >> > forever.
> >> > Assume one of the worker is not able to start (not able to attach
> >> > to shared memory or some other reason), then status returned by
> >> > GetBackgroundWorkerPid() will be BGWH_NOT_YET_STARTED
> >> > and after that it can wait forever in WaitLatch.
> >>
> >> I don't think that's right. The status only remains
> >> BGWH_NOT_YET_STARTED until the postmaster forks the child process.
> >
> > I think the control flow can reach the above location before
> > postmaster could fork all the workers. Consider a case that
> > we have launched all workers during ExecutorStart phase
> > and then before postmaster could start all workers an error
> > occurs in master backend and then it try to Abort the transaction
> > and destroy the parallel context, at that moment it will get the
> > above status and wait forever in above code.
> >
> > I am able to reproduce above scenario with debugger by using
> > parallel_seqscan patch.
>
> Hmm. Well, if you can reproduce it, there clearly must be a bug. But
> I'm not quite sure where. What should happen in that case is that the
> process that started the worker has to wait for the postmaster to
> actually start it,
Okay, I think this should solve the issue, also it should be done
before call of TerminateBackgroundWorker().