Re: wake up logical workers after ALTER SUBSCRIPTION
От | Amit Kapila |
---|---|
Тема | Re: wake up logical workers after ALTER SUBSCRIPTION |
Дата | |
Msg-id | CAA4eK1JFgvhxV448uNTkKpQpGe+X8WRWtyf45h4vASEpNz3Gkw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: wake up logical workers after ALTER SUBSCRIPTION (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: wake up logical workers after ALTER SUBSCRIPTION
|
Список | pgsql-hackers |
On Thu, Jan 5, 2023 at 10:16 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Wed, Jan 04, 2023 at 08:12:37PM -0800, Nathan Bossart wrote: > > On Thu, Jan 05, 2023 at 09:09:12AM +0530, Amit Kapila wrote: > >> But there doesn't appear to be any guarantee that the result for > >> AllTablesyncsReady() will change between the time it is invoked > >> earlier in the function and at the place you have it in the patch. > >> This is because the value of 'table_states_valid' may not have > >> changed. So, how is this supposed to work? > > > > The call to CommandCounterIncrement() should set table_states_valid to > > false if needed. > > In v12, I moved the restart for two_phase mode to the end of > process_syncing_tables_for_apply() so that we don't need to rely on another > iteration of the loop. > This should work but it is better to add a comment before calling CommandCounterIncrement() to indicate that this is for making changes to the relation state visible. Thinking along similar lines, won't apply worker need to be notified of SUBREL_STATE_SYNCWAIT state change by the tablesync worker? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: