Re: [HACKERS] parallel.c oblivion of worker-startup failures

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] parallel.c oblivion of worker-startup failures
Date: 2018-01-24 04:33:14
Message-ID: CAH2-WzkwNJ13sOyV9Q-BqZHOYV9TBaME0D1Dg+2PjHJvkBuzHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 23, 2018 at 8:25 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> Hmm, I think that case will be addressed because tuple queues can
>> detect if the leader is not attached. It does in code path
>> shm_mq_receive->shm_mq_counterparty_gone. In
>> shm_mq_counterparty_gone, it can detect if the worker is gone by using
>> GetBackgroundWorkerPid. Moreover, I have manually tested this
>> particular case before saying your patch is fine. Do you have some
>> other case in mind which I am missing?
>
> Hmm. Yeah. I can't seem to reach a stuck case and was probably just
> confused and managed to confuse Robert too. If you make
> fork_process() fail randomly (see attached), I see that there are a
> couple of easily reachable failure modes (example session at bottom of
> message):
>
> 1. HandleParallelMessages() is reached and raises a "lost connection
> to parallel worker" error because shm_mq_receive() returns
> SHM_MQ_DETACHED, I think because shm_mq_counterparty_gone() checked
> GetBackgroundWorkerPid() just as you said. I guess that's happening
> because some other process is (coincidentally) sending
> PROCSIG_PARALLEL_MESSAGE at shutdown, causing us to notice that a
> process is unexpectedly stopped.
>
> 2. WaitForParallelWorkersToFinish() is reached and raises a "parallel
> worker failed to initialize" error. TupleQueueReaderNext() set done
> to true, because shm_mq_receive() returned SHM_MQ_DETACHED. Once
> again, that is because shm_mq_counterparty_gone() returned true. This
> is the bit Robert and I missed in our off-list discussion.
>
> As long as we always get our latch set by the postmaster after a fork
> failure (ie kill SIGUSR1) and after GetBackgroundWorkerPid() is
> guaranteed to return BGWH_STOPPED after that, and as long as we only
> ever use latch/CFI loops to wait, and as long as we try to read from a
> shm_mq, then I don't see a failure mode that hangs.

What about the parallel_leader_participation=off case?

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-01-24 04:36:17 Re: [HACKERS] parallel.c oblivion of worker-startup failures
Previous Message Abinaya k 2018-01-24 04:27:18 Regarding ambulkdelete, amvacuumcleanup index methods