Re: Parallel query hangs after a smart shutdown is issued

Thomas Munro <thomas.munro@gmail.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