On Wed, Dec 14, 2022 at 12:42:32PM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> 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.
>
> No, I'm still of the opinion that waiting for the launcher to timeout
> before doing something is fundamentally wrong design. We should signal
> it when we want it to do something. That's not different from what
> you're fixing about the workers; why don't you see that it's appropriate
> for the launcher too?
I'm reasonably certain the launcher is already signaled like you describe.
It'll just wait to start new workers if it's been less than
wal_retrieve_retry_interval milliseconds since the last time it started
workers.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com