Alexander Kukushkin <cyberdemn@gmail.com> writes:
> I the fast shutdown was initiated before pg_prewarm managed to load
> buffers from the dump (and start the main loop), the pg_prewarm
> bgworker process never exits on SIGTERM and effectively preventing the
> clean shutdown of the cluster.
I might be wrong about this, but I suspect what you've got here is that
the postmaster never launched the child bgworker (and now never will
launch it), so GetBackgroundWorkerPid returns BGWH_NOT_YET_STARTED
and then WaitForBackgroundWorkerShutdown keeps on waiting. If that
interpretation is accurate then the same problem could occur with
parallel query. (And I believe it's been sufficiently demonstrated
that parallel query falls over very easily in such corner cases,
so this isn't an astonishing conclusion.)
I'm inclined to think what we need to do about this is to have
the postmaster transition all pending worker-start requests into
STOPPED state, or some new FAILED state, when it starts trying to
shut stuff down. I sure don't see any such logic there now ---
it just sends out a bunch of SIGTERMs and that's it. Also,
it looks like bgworker_should_start_now() doesn't distinguish
postmaster states that don't allow starting a bgworker right
this moment, but probably will allow it later, from states in
which it never will be allowed and we need to fail the request
not just postpone it indefinitely.
regards, tom lane
