Re: [HACKERS] Re: Alter subscription..SET - NOTICE message is comingfor table which is already removed
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Re: Alter subscription..SET - NOTICE message is comingfor table which is already removed |
Дата | |
Msg-id | CAD21AoDGWUs_WQ8uEgkgJZ2=OAo6_ZhtTkPDSJeJJUbDOZWHjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Alter subscription..SET - NOTICE message is comingfor table which is already removed (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Список | pgsql-hackers |
On Mon, Jun 12, 2017 at 9:56 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > 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. > Thank you for committing the patch. Yes, I understood. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: