Re: wake up logical workers after ALTER SUBSCRIPTION
От | Nathan Bossart |
---|---|
Тема | Re: wake up logical workers after ALTER SUBSCRIPTION |
Дата | |
Msg-id | 20221123205027.GA368966@nathanxps13 обсуждение исходный текст |
Ответ на | RE: wake up logical workers after ALTER SUBSCRIPTION ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
Ответы |
RE: wake up logical workers after ALTER SUBSCRIPTION
|
Список | pgsql-hackers |
On Tue, Nov 22, 2022 at 07:25:36AM +0000, houzj.fnst@fujitsu.com wrote: > On Tuesday, November 22, 2022 2:49 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> >> Thanks for updating! It becomes better. Further comments: >> >> 01. AlterSubscription() >> >> ``` >> + LogicalRepWorkersWakeupAtCommit(subid); >> + >> ``` >> >> Currently subids will be recorded even if the subscription is not modified. >> I think LogicalRepWorkersWakeupAtCommit() should be called inside the if >> (update_tuple). > > I think an exception would be REFRESH PULLICATION in which case update_tuple is > false, but it seems better to wake up apply worker in this case as well, > because the apply worker is also responsible to start table sync workers for > newly subscribed tables(in process_syncing_tables()). > > Besides, it seems not a must to wake up apply worker for ALTER SKIP TRANSACTION, > Although there might be no harm for waking up in this case. In v3, I moved the call to LogicalRepWorkersWakeupAtCommit() to the end of the function. This should avoid waking up workers in some cases where it's unnecessary (e.g., if ALTER SUBSCRIPTION ERRORs in a subtransaction), but there are still cases where we'll wake up the workers unnecessarily. I think this is unlikely to cause any real problems in practice. >> 02. LogicalRepWorkersWakeupAtCommit() >> >> ``` >> + oldcxt = MemoryContextSwitchTo(TopTransactionContext); >> + on_commit_wakeup_workers_subids = >> lappend_oid(on_commit_wakeup_workers_subids, >> + >> subid); >> ``` >> >> If the subscription is altered twice in the same transaction, the same subid will >> be recorded twice. >> I'm not sure whether it may be caused some issued, but list_member_oid() can >> be used to avoid that. > > +1, list_append_unique_oid might be better. Done in v3. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: