Re: wake up logical workers after ALTER SUBSCRIPTION

Поиск
Список
Период
Сортировка
От Melih Mutlu
Тема Re: wake up logical workers after ALTER SUBSCRIPTION
Дата
Msg-id CAGPVpCTUuKyxB5f3exgDMBRTivbN5uHVkD=YfXmgznrdnwVOQw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: wake up logical workers after ALTER SUBSCRIPTION  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: wake up logical workers after ALTER SUBSCRIPTION  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
Hi Nathan,

@@ -410,6 +411,12 @@ ExecRenameStmt(RenameStmt *stmt)
    stmt->newname);
  table_close(catalog, RowExclusiveLock);
 
+ /*
+ * Wake up the logical replication workers to handle this
+ * change quickly.
+ */
+ LogicalRepWorkersWakeupAtCommit(address.objectId);

Is it really necessary to wake logical workers up when renaming other than subscription or publication? address.objectId will be a valid subid only when renaming a subscription.

@@ -322,6 +323,9 @@ UpdateSubscriptionRelState(Oid subid, Oid relid, char state,
 
  /* Cleanup. */
  table_close(rel, NoLock);
+
+ /* Wake up the logical replication workers to handle this change quickly. */
+ LogicalRepWorkersWakeupAtCommit(subid);
 
I wonder why a wakeup call is needed every time a subscription relation is updated.
It seems to me that there are two places where UpdateSubscriptionRelState is called and we need another worker to wake up:
- When a relation is in SYNCWAIT state, it waits for the apply worker to wake up and change the relation state to CATCHUP. Then tablesync worker needs to wake up to continue from CATCHUP state.
- When the state is SYNCDONE and the apply worker has to wake up to change the state to READY.

I think we already call logicalrep_worker_wakeup_ptr wherever it's needed for the above cases? What am I missing here?

Best,
--
Melih Mutlu
Microsoft

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Error-safe user functions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Error-safe user functions