Craig, Andres what do you thinks about previous message? 2016-10-06 0:35 GMT+03:00 Vladimir Gordiychuk <fol...@gmail.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 <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 >> > >
