One idea is to change the standby so that it manages the locations that the backends in "apply" mode are waiting for in the master, and to make the startup process wake the walreceiver up whenever the replay location reaches either of those locations. In this idea, walreceiver sends back the "apply" location to the master only when needed.
Hmm. So maybe commit records could have a flag saying 'someone is waiting for this to commit to apply', and the startup process's apply loop would only bother to signal the walreceiver if it sees that flag. I will try that.
Here is a version that does that, using a bit in xinfo to request apply feedback from standbys when running with synchronous_commit = apply.
I am not very happy with the way that xact_redo communicates with the main apply loop when it sees that bit, through calls to XLogAppliedSynchronousCommit (essentially a global variable), but I couldn't immediately see a better way to get information out of xact_redo into the apply loop without changing the rm_redo interface. Perhaps xinfo is the wrong place for that information. Thoughts?
