> 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 <cr...@2ndquadrant.com>: > On 5 October 2016 at 05:14, Andres Freund <and...@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 <fol...@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 >
