]> granicus.if.org Git - postgresql/commit
Report failure to start a background worker.
authorRobert Haas <rhaas@postgresql.org>
Wed, 6 Dec 2017 13:49:30 +0000 (08:49 -0500)
committerRobert Haas <rhaas@postgresql.org>
Wed, 6 Dec 2017 13:58:27 +0000 (08:58 -0500)
commit28724fd90d2f85a0573a8107b48abad062a86d83
treefb92be3f2385e1a9373673fdebfab6e2c4c00a1b
parent9c64ddd414855fb10e0355e887745270a4464c50
Report failure to start a background worker.

When a worker is flagged as BGW_NEVER_RESTART and we fail to start it,
or if it is not marked BGW_NEVER_RESTART but is terminated before
startup succeeds, what BgwHandleStatus should be reported?  The
previous code really hadn't considered this possibility (as indicated
by the comments which ignore it completely) and would typically return
BGWH_NOT_YET_STARTED, but that's not a good answer, because then
there's no way for code using GetBackgroundWorkerPid() to tell the
difference between a worker that has not started but will start
later and a worker that has not started and will never be started.
So, when this case happens, return BGWH_STOPPED instead.  Update the
comments to reflect this.

The preceding fix by itself is insufficient to fix the problem,
because the old code also didn't send a notification to the process
identified in bgw_notify_pid when startup failed.  That might've
been technically correct under the theory that the status of the
worker was BGWH_NOT_YET_STARTED, because the status would indeed not
change when the worker failed to start, but now that we're more
usefully reporting BGWH_STOPPED, a notification is needed.

Without these fixes, code which starts background workers and then
uses the recommended APIs to wait for those background workers to
start would hang indefinitely if the postmaster failed to fork a
worker.

Amit Kapila and Robert Haas

Discussion: http://postgr.es/m/CAA4eK1KDfKkvrjxsKJi3WPyceVi3dH1VCkbTJji2fuwKuB=3uw@mail.gmail.com
src/backend/postmaster/bgworker.c
src/backend/postmaster/postmaster.c