From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Alter subscription..SET - NOTICE message is coming for table which is already removed |
Date: | 2017-06-12 12:56:58 |
Message-ID: | ab7c87a3-fd4e-b387-fac6-6d1ba5a06a8c@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-06-12 13:03:00 | Re: remove unnecessary flag has_null from PartitionBoundInfoData |
Previous Message | wangchuanting | 2017-06-12 12:47:59 | Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog |