• Tom Lane's avatar
    Fix some minor postmaster-state-machine issues. · 0fae8462
    Tom Lane authored
    In sigusr1_handler, don't ignore PMSIGNAL_ADVANCE_STATE_MACHINE based
    on pmState.  The restriction is unnecessary (PostmasterStateMachine
    should work in any state), not future-proof (since it makes too many
    assumptions about why the signal might be sent), and broken even today
    because a race condition can make it necessary to respond to the signal
    in PM_WAIT_READONLY state.  The race condition seems unlikely, but
    if it did happen, a hot-standby postmaster could fail to shut down
    after receiving a smart-shutdown request.
    
    In MaybeStartWalReceiver, don't clear the WalReceiverRequested flag
    if the fork attempt fails.  Leaving it set allows us to try
    again in future iterations of the postmaster idle loop.  (The startup
    process would eventually send a fresh request signal, but this change
    may allow us to retry the fork sooner.)
    
    Remove an obsolete comment and unnecessary test in
    PostmasterStateMachine's handling of PM_SHUTDOWN_2 state.  It's not
    possible to have a live walreceiver in that state, and AFAICT has not
    been possible since commit 5e85315e.  This isn't a live bug, but the
    false comment is quite confusing to readers.
    
    In passing, rearrange sigusr1_handler's CheckPromoteSignal tests so that
    we don't uselessly perform stat() calls that we're going to ignore the
    results of.
    
    Add some comments clarifying the behavior of MaybeStartWalReceiver;
    I very nearly rearranged it in a way that'd reintroduce the race
    condition fixed in e5d494d7.  Mea culpa for not commenting that
    properly at the time.
    
    Back-patch to all supported branches.  The PMSIGNAL_ADVANCE_STATE_MACHINE
    change is the only one of even minor significance, but we might as well
    keep this code in sync across branches.
    
    Discussion: https://postgr.es/m/9001.1556046681@sss.pgh.pa.us
    0fae8462
postmaster.c 180 KB