Re: Getting error at the time of dropping subscription and few more issues

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: Getting error at the time of dropping subscription and few more issues
Date: 2017-05-19 01:17:53
Message-ID: CAD21AoCHgZHia-8bCgfsC0PPUsQ6Pw+XrAh0+qT9o7Zc48ANMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 19, 2017 at 9:54 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 5/12/17 13:25, Masahiko Sawada wrote:
>>> postgres=# alter subscription sub set publication pub refresh;
>>> NOTICE: removed subscription for table public.t1
>>> NOTICE: removed subscription for table public.t2
>>> ALTER SUBSCRIPTION
>>>
>>> I think - in publication too ,we should provide NOTICE messages.
>>>
>> I guess one of the reason why we emit such a NOTICE message is that
>> subscriber cannot control which table the upstream server replicate.
>> So if a table got disassociated on the publisher the subscriber should
>> report that to user. On the other hand, since the publication can
>> control it and the changes are obvious, I'm not sure we really need to
>> do that.
>>
>> BTW I think it's better for the above NOTICE message to have subscription name.
>
> Why? These come directly has a result of the ALTER SUBSCRIPTION
> command, so you see what they refer to.
>

Because I thought it would be helpful for DBA when the log is appeared
in server log. It doesn't appear by default though.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-05-19 01:39:49 Re: Fix refresh_option syntax of ALTER SUBSCRIPTION in document
Previous Message Peter Eisentraut 2017-05-19 01:14:17 Re: Re: proposal - using names as primary names of plpgsql function parameters instead $ based names