On Tue, Dec 13, 2022 at 04:41:05PM -0800, Nathan Bossart wrote:
> On Tue, Dec 13, 2022 at 07:20:14PM -0500, Tom Lane wrote:
>> 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.
>
> This parameter appears to control how often the apply launcher starts new
> workers. If it starts new workers in a loop iteration, it updates its
> last_start_time variable, and it won't start any more workers until another
> wal_retrieve_retry_interval has elapsed. If no new workers need to be
> started, it only wakes up every 3 minutes.
Looking closer, I see that wal_retrieve_retry_interval is used for three
purposes. It's main purpose seems to be preventing busy-waiting in
WaitForWALToBecomeAvailable(), as that's what's documented. But it's also
used for logical replication. The apply launcher uses it as I've describe
above, and the apply workers use it when launching sync workers. Unlike
the apply launcher, the apply workers store the last start time for each
table's sync worker and use that to determine whether to start a new one.
My first thought is that the latter two uses should be moved to a new
parameter, and the apply launcher should store the last start time for each
apply worker like the apply workers do for the table-sync workers. In any
case, it probably makes sense to lower this parameter's value for testing
so that tests that restart these workers frequently aren't waiting for so
long.
I can put a patch together if this seems like a reasonable direction to go.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
