> We're about halfway there already, see 7e784d1dc. I didn't do the
> other half because it wasn't necessary to the problem, but exposing
> the shutdown state more fully seems reasonable.
Excellent, I'll take a look. Thanks.
That looks very handy already.
Extending it to be set before SIGTERM too would be handy.
My suggestion, which I'm happy to post in patch form if you think it's reasonable:
* Change QuitSignalReason to ExitSignalReason to cover both SIGTERM (fast) and SIGQUIT (immediate)
* Rename PMQUIT_FOR_STOP to PMEXIT_IMMEDIATE_SHUTDOWN
* Add enumeration values PMEXIT_SMART_SHUTDOWN and PMEXIT_FAST_SHUTDOWN
* For a fast shutdown, in pmdie()'s SIGINT case call SetExitSignalReason(PMEXIT_FAST_SHUTDOWN), so that when PostmasterStateMachine() calls SignalSomeChildren(SIGTERM, ...) in response to PM_STOP_BACKENDS, the reason is already available.
* For smart shutdown, in pmdie()'s SIGTERM case call SetExitSignalReason(PMEXIT_SMART_SHUTDOWN) and set the latch of every live backend. There isn't any appropriate PROCSIG so unless we want to overload PROCSIG_WALSND_INIT_STOPPING (ick), but I think it'd generally be sufficient to check GetExitSignalReason() in backend main loops.
The fast shutdown case seems like a no-brainer extension of your existing patch.
I'm not entirely sure about the smart shutdown case. I don't want to add a ProcSignal slot just for this and the info isn't urgent anyway. I think that by checking for postmaster shutdown in the backend main loop we'd be able to support eager termination of idle backends on smart shutdown (immediately, or after an idle grace period), which is something I've wanted for quite some time. It shouldn't be significantly expensive especially in the idle loop.
(Also I want a hook in PostgresMain's idle loop for things like this).
