Re: Stopping logical replication protocol

Craig, Andres what do you thinks about previous message?

2016-10-06 0:35 GMT+03:00 Vladimir Gordiychuk <folyga(at)gmail(dot)com>:

> > Vladimir? I'm running out of time to spend on this at least until the next
> CF. Think you can make these changes?
>
> Yes, I can. But I thinks It should be discuss first.
>
> > Terminating COPY BOTH with ERRCODE_QUERY_CANCELED seems fine. If it
> > was expecting the error the client can Sync and do whatever it next
> > wants to do on the walsender protocol, or bail out nicely.
>
> Do you want return CopyFail with ERRCODE_QUERY_CANCELED instead of
> CopyDone on client initialized stop replication?
>
> > Hm, I'm *VERY* doubtful about doing this via yet another callback. Why
> > don't we just error out in the prepare write callback?
>
> But what about scenario when output plugin collect changes in memory with
> some transformation and send it only inside commit_cb?
> It means that OutputPluginPrepareWrite will not execute until end
> transaction and we face with too long stops replication when decodes huge
> transaction.
>
> 2016-10-05 13:06 GMT+03:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
>
>> On 5 October 2016 at 05:14, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> > Hi,
>> >
>> > On 2016-09-23 13:01:27 +0800, Craig Ringer wrote:
>> >> From f98f2388c57d938ebbe07ccd2dbe02138312858f Mon Sep 17 00:00:00 2001
>> >> From: Vladimir Gordiychuk <folyga(at)gmail(dot)com>
>> >> Date: Wed, 7 Sep 2016 00:39:18 +0300
>> >> Subject: [PATCH 2/4] Client-initiated CopyDone during transaction
>> decoding in
>> >> walsender
>> >>
>> >> The prior patch caused the walsender to react to a client-initiated
>> >> CopyDone while it's in the WalSndLoop. That's not enough to let clients
>> >> end logical decoding mid-transaction because we loop in
>> ReorderBufferCommit
>> >> during decoding of a transaction without ever returning to WalSndLoop.
>> >>
>> >> Allow breaking out of ReorderBufferCommit by detecting that client
>> >> input has requested an end to COPY BOTH mode, so clients can abort
>> >> decoding mid-transaction.
>> >
>> > Hm, I'm *VERY* doubtful about doing this via yet another callback. Why
>> > don't we just error out in the prepare write callback?
>>
>> That's sensible.
>>
>> > I don't think it's a good idea to return a non-error state if a command
>> > is interrupted in the middle. We might already have sent a partial
>> > transaction or such. Also compare this to interrupting a query - we
>> > don't just returning rows, we error out.
>>
>> Good point. It's not usually visible to the user because if it's a
>> client-initiated cancel the client will generally consume the error,
>> but there's still an error generated.
>>
>> Terminating COPY BOTH with ERRCODE_QUERY_CANCELED seems fine. If it
>> was expecting the error the client can Sync and do whatever it next
>> wants to do on the walsender protocol, or bail out nicely.
>>
>> Vladimir? I'm running out of time to spend on this at least until the
>> next CF. Think you can make these changes?
>>
>>
>> --
>> Craig Ringer http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>