Re: High CPU consumption in cascade replication with large number of walsenders and ConditionVariable broadcast issues

After playing with the patch a little more, we’ve come to the 
conclusion, that the idea to signal CV broadcast from the timer handler 
is a risky one, as it creates a large number of execution paths, which 
are not present in current code base. It's hard to prove correctness of 
application behavior in each such case, so we've decided to use a 
different approach.

In the new version of the patch we use timer handler only to set the 
flag, which is then checked in the ProcessStartupProcInterrupts 
function. This allow us to send signal on timeout if the startup process 
is waiting for the arrival of new WAL records (in ReadRecord), but the 
notification may be delayed while record is being applied (during redo 
handler invocation from ApplyWalRecord). This could increase delay for 
some corner cases with non-trivial WAL records like ‘drop database’, but 
this should be a rare case and walsender process have its own limit on 
the wait time, so the delay won’t be indefinite even in this case.

A new variant of the patch is attached in case anybody else wants to 
play with this patch and approach. A slightly improved test case and 
formatted CV patch (which is not strictly required anymore for this 
case) are attached as well.

Thanks,
Alexey