From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | 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: | 2017-12-12 03:30:08 |
Message-ID: | CAA4eK1+87DECjb0r16YJJtgZ72_OioPpmTWWgRzvfrsC11uLJg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 11, 2017 at 11:27 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> Okay, see the attached and let me know if that suffices the need?
>
> + * Check for unexpected worker death. This will ensure that if
> + * the postmaster failed to start the worker, then we don't wait
> + * for it indefinitely. For workers that are known to be
> + * launched, we can rely on their error queue being freed once
> + * they exit.
>
> Hmm. Is this really true? What if the worker starts up but then
> crashes before attaching to the error queue?
>
If the worker errored out before attaching to the error queue, then we
can't rely on error queue being freed. However, in that case, the
worker status will be BGWH_STOPPED. I have adjusted the comment
accordingly.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
fix_parallel_worker_startup_failures_v2.patch | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-12-12 03:41:01 | Re: BUG #14941: Vacuum crashes |
Previous Message | Alvaro Herrera | 2017-12-12 03:04:54 | Re: [HACKERS] Proposal: Local indexes for partitioned table |