Re: [HACKERS] parallel.c oblivion of worker-startup failures
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-12-12T03:41:25Z
Lists: pgsql-hackers
On Tue, Dec 12, 2017 at 9:00 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Mon, Dec 11, 2017 at 11:27 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila <amit.kapila16@gmail.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. > In particular, if the worker crashed (say somebody forcefully killed the worker), then I think it will lead to a restart of the server. So not sure, adding anything about that in the comment will make much sense. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Report an ERROR if a parallel worker fails to start properly.
- 2843c01a56eb 9.6.7 landed
- 383e4268ff8c 10.2 landed
- 2badb5afb89c 11.0 landed
-
Report failure to start a background worker.
- facd94e72f27 9.4.16 landed
- 0426a77ce465 9.5.11 landed
- b75644066091 9.6.7 landed
- a8ef4e81e6f2 10.2 landed
- 28724fd90d2f 11.0 landed