On Thu, Aug 13, 2020 at 10:21 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@gmail.com> writes: > > @@ -5911,11 +5912,11 @@ bgworker_should_start_now(BgWorkerStartTime > > start_time) > > + case PM_WAIT_READONLY: > > + case PM_WAIT_CLIENTS: > > case PM_RUN: > > So the question here is whether time-based bgworkers should be allowed to > restart in this scenario. I'm not quite sure --- depending on what the > bgworker's purpose is, you could make an argument either way, I think. > Do we need some way to control that?
I'm not sure why any bgworker would actually want to be shut down or not restarted during the twilight zone of a smart shutdown though -- if users can do arbitrary stuff, why can't supporting workers carry on? For example, a hypothetical extension that triggers vacuum freeze at smarter times, or a wait event sampling extension, an FDW that uses an extra worker to maintain a connection to something, etc etc could all be things that a user is indirectly relying on to do their normal work, and I struggle to think of an example of something that you explicitly don't want running just because (in some sense) the server *plans* to shut down, when the users get around to logging off. But maybe I lack imagination. > In any case, we'd want to treat PM_WAIT_READONLY like PM_HOT_STANDBY not > PM_RUN, no? Yeah, you're right. > Also, the state before PM_WAIT_READONLY could have been > PM_RECOVERY or PM_STARTUP, in which case we don't really want to think > it's like PM_HOT_STANDBY either; only the BgWorkerStart_PostmasterStart > case should be accepted. That suggests that we need yet another pmState, > or else a more thoroughgoing refactoring of how the postmaster's state > is represented. Hmm.
