Re: subscription worker doesn't start immediately on eabled

On Thu, Apr 27, 2017 at 6:32 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> At Thu, 27 Apr 2017 00:51:03 +0900, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote in <CAHGQGwEQH4V2aU=wbA4Mcc+uRsrLS2rpRONLZyB2EL=f=UNypA(at)mail(dot)gmail(dot)com>
>> On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
>> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> > At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote in <3d6a1bd0-08ce-301d-3336-ec9f623a315d(at)2ndquadrant(dot)com>
>> >> On 4/6/17 08:24, Kyotaro HORIGUCHI wrote:
>> >> > The attached patch wakes up launcher when a subscription is
>> >> > enabled. This fails when a subscription is enabled immedaitely
>> >> > after disabling but it won't be a matter.
>> >>
>> >> committed, thanks
>> >
>> > Thanks!
>>
>> This patch makes me think that CREATE SUBSCRIPTION should also wake up
>> the launcher only when ENABLE is specified. Patch attached. Thought?
>
> I don't think it works as expected. Disabling of a subsciption is
> detected by the *worker* itself then it terminates by
> itself. Only open apply transactions can prevent the behavior.

Sorry I could not understand your point. Could you elaborate this?

Since the launcher starts up the worker only when its subscription is enabled,
ISTM that CREATE SUBSCRIPTION .. DISABLE doesn't need to wake up
the launcher. Even if the launcher wakes up, it doesn't start up the worker
because its subscription is not enabled.

Regards,

--
Fujii Masao