Re: Suppressing useless wakeups in walreceiver

On Wed, Nov 16, 2022 at 5:24 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> On Wed, Nov 16, 2022 at 04:57:08PM +1300, Thomas Munro wrote:
> > On Tue, Nov 15, 2022 at 5:49 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> >> Another option might be to just force initial reply/feedback messages when
> >> streaming starts. The attached patch improves src/test/recovery test
> >> runtime just like the previous one I posted.
> >
> > Yeah, looks good in my tests. I think we just need to make it
> > conditional so we don't force it if someone has
> > wal_receiver_status_interval disabled.
>
> Yeah, that makes sense. IIUC setting "force" to false would have the same
> effect for the initial round of streaming, but since writePtr/flushPtr will
> be set in later rounds, no reply would be guaranteed. That might be good
> enough for the tests, but it seems a bit inconsistent. So, your patch is
> probably the way to go.

On second thoughts, there's not much point in that, since we always
force replies under various other circumstances anyway. There isn't
really a 'never send replies' mode. Committed the way you had it
before. Thanks!

I can't unsee that we're spending ~35 seconds waiting for catchup in
718 separate wait_for_catchup calls. The problem is entirely on the
waiting side (we already do WalRcvForceReply() in xlogrecovery.c when
going idle), and there's probably a nice condition variable-based
improvement here but I decided to hop over that rabbit hole today.