Re: [HACKERS] Re: Alter subscription..SET - NOTICE message is comingfor table which is already removed
| От | Peter Eisentraut |
|---|---|
| Тема | Re: [HACKERS] Re: Alter subscription..SET - NOTICE message is comingfor table which is already removed |
| Дата | |
| Msg-id | ab7c87a3-fd4e-b387-fac6-6d1ba5a06a8c@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Re: Alter subscription..SET - NOTICE message is comingfor table which is already removed (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: [HACKERS] Re: Alter subscription..SET - NOTICE message is comingfor table which is already removed
|
| Список | pgsql-hackers |
On 6/11/17 21:40, Masahiko Sawada wrote: > Thank you for the patch. The patch fixes this issue but it takes a > long time to done ALTER SUBSCRIPTION SET PUBLICATION when > max_sync_workers_per_subscription is set high value. Because the > removing entry from pg_subscription_rel and launching a new table sync > worker select a subscription relation state in the same order, the > former doesn't catch up with latter. > For example in my environment, when I test the following step with > max_sync_workers_per_subscription = 15, all table sync workers were > launched once and then killed. How about removing the entry from > pg_subscription_rel in the inverse order? I have committed the patch as is. Optimizations might be possible, but let's keep in mind that the use case of changing the subscription right after it was created is a pretty marginal case to begin with. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: