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