From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(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 13:47:04 |
Message-ID: | CAD21AoDGWUs_WQ8uEgkgJZ2=OAo6_ZhtTkPDSJeJJUbDOZWHjQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 12, 2017 at 9:56 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-06-12 14:04:41 | Re: Proposal : For Auto-Prewarm. |
Previous Message | Ashutosh Bapat | 2017-06-12 13:03:00 | Re: remove unnecessary flag has_null from PartitionBoundInfoData |