Re: Parallel query hangs after a smart shutdown is issued

On Thu, Aug 13, 2020 at 10:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@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.