Re: wake up logical workers after ALTER SUBSCRIPTION
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Melih Mutlu <m.melihmutlu@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-12-14T17:45:35Z
Lists: pgsql-hackers
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
Commits
-
Avoid type cheats for invalid dsa_handles and dshash_table_handles.
- 3b4ac33254e1 16.0 landed
-
Track logrep apply workers' last start times to avoid useless waits.
- 5a3a95385bd5 16.0 landed
-
Check for two_phase change at end of process_syncing_tables_for_apply.
- 4c032dd8046b 16.0 landed
-
Wake up a subscription's replication worker processes after DDL.
- c6e1f62e2cee 16.0 landed