RE: Single transaction in the tablesync worker?
От | Hou, Zhijie |
---|---|
Тема | RE: Single transaction in the tablesync worker? |
Дата | |
Msg-id | 3e2e89b50aa84c48b8f39f30a904593e@G08CNEXMBPEKD05.g08.fujitsu.local обсуждение исходный текст |
Ответ на | Re: Single transaction in the tablesync worker? (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: Single transaction in the tablesync worker?
|
Список | pgsql-hackers |
> Also PSA some detailed logging evidence of some test scenarios involving > Drop/AlterSubscription: > + Test-20210112-AlterSubscriptionRefresh-ok.txt = > AlterSubscription_refresh which successfully drops a tablesync slot > + Test-20210112-AlterSubscriptionRefresh-warning.txt = > AlterSubscription_refresh gives WARNING that it cannot drop the tablesync > slot (which no longer exists) > + Test-20210112-DropSubscription-warning.txt = DropSubscription with a > disassociated slot_name gives a WARNING that it cannot drop the tablesync > slot (due to broken connection) Hi > * The AlterSubscription_refresh (v14+) is now more similar to DropSubscription w.r.t to stopping workers for any "removed"tables. I have an issue about the above feature. With the patch, it seems does not stop the worker in the case of [1]. I probably missed something, should we stop the worker in such case ? [1] https://www.postgresql.org/message-id/CALj2ACV%2B0UFpcZs5czYgBpujM9p0Hg1qdOZai_43OU7bqHU_xw%40mail.gmail.com Best regards, houzj
В списке pgsql-hackers по дате отправления: