Re: Stopping logical replication protocol - Mailing list pgsql-hackers

> 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@2ndquadrant.com>:

On 5 October 2016 at 05:14, Andres Freund <andres@anarazel.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@gmail.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