Re: Parallel query hangs after a smart shutdown is issued

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> I think we also need:

> + else if (Shutdown <= SmartShutdown &&
> + backend_type == BACKEND_TYPE_AUTOVAC)
> + result = CAC_OK;

Hm, ok.

> Retesting the original complaint, I think we need:

> @@ -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?

In any case, we'd want to treat PM_WAIT_READONLY like PM_HOT_STANDBY not
PM_RUN, no? 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.

regards, tom lane