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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
