On Wed, Nov 16, 2022 at 5:24 PM Nathan Bossart <nathandboss...@gmail.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 <nathandboss...@gmail.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.
