Nathan Bossart <nathandbossart@gmail.com> writes:
> On Tue, Dec 13, 2022 at 06:32:08PM -0500, Tom Lane wrote:
>> I've not chased it further than that, but I venture that the apply
>> launcher also needs a kick in the pants, and/or there needs to be
>> an interlock to ensure that it doesn't wake until after the old
>> apply worker quits.
> This is probably because the tests set wal_retrieve_retry_interval to
> 500ms. Lowering that to 1ms in Cluster.pm seems to wipe out this
> particular wait, and the total src/test/subscription test time drops from
> 119 seconds to 95 seconds on my machine.
That's not really the direction we should be going in, though. Ideally
there should be *no* situation where we are waiting for a timeout to
elapse for a process to wake up and notice it ought to do something.
If we have timeouts at all, they should be backstops for the possibility
of a lost interrupt, and it should be possible to set them quite high
without any visible impact on normal operation. (This gets back to
the business about minimizing idle power consumption, which Simon was
bugging us about recently but that's been on the radar screen for years.)
I certainly don't think that "wake the apply launcher every 1ms"
is a sane configuration. Unless I'm missing something basic about
its responsibilities, it should seldom need to wake at all in
normal operation.
regards, tom lane