On Mon, Jun 12, 2017 at 9:56 PM, Peter Eisentraut <peter.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers