Re: [HACKERS] Stopping logical replication protocol

On Fri, Nov 4, 2016 at 12:44 AM, Craig Ringer wrote: > On 21 October 2016 at 19:38, Vladimir Gordiychuk wrote: > > Craig, Andres what do you thinks about previous message? > > I haven't had a chance to look further to be honest. > > Since a downstream

Re: [HACKERS] Stopping logical replication protocol

On 21 October 2016 at 19:38, Vladimir Gordiychuk wrote: > Craig, Andres what do you thinks about previous message? I haven't had a chance to look further to be honest. Since a downstream disconnect works, though it's ugly, it's not something I can justify spending a lot of

Re: [HACKERS] Stopping logical replication protocol

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

Re: [HACKERS] Stopping logical replication protocol

> 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

Re: [HACKERS] Stopping logical replication protocol

On 5 October 2016 at 05:14, Andres Freund 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 >> Date: Wed, 7 Sep 2016 00:39:18 +0300 >>

Re: [HACKERS] Stopping logical replication protocol

Hi, On 2016-09-23 13:01:27 +0800, Craig Ringer wrote: > From f98f2388c57d938ebbe07ccd2dbe02138312858f Mon Sep 17 00:00:00 2001 > From: Vladimir Gordiychuk > Date: Wed, 7 Sep 2016 00:39:18 +0300 > Subject: [PATCH 2/4] Client-initiated CopyDone during transaction decoding in >

Re: [HACKERS] Stopping logical replication protocol

> Vladimir, can I have your opinion on the latest patch or if you want to make changes, an updated patch? I am satisfied with all our changes and I thinks it enough to complete this PR. 2016-10-03 6:51 GMT+03:00 Craig Ringer : > On 3 Oct. 2016 10:15, "Michael Paquier"

Re: [HACKERS] Stopping logical replication protocol

On 3 Oct. 2016 10:15, "Michael Paquier" wrote: > > On Tue, Sep 27, 2016 at 11:05 AM, Craig Ringer wrote: > > On 26 September 2016 at 21:52, Vladimir Gordiychuk wrote: > >>>You should rely on time I tests as little as possible.

Re: [HACKERS] Stopping logical replication protocol

On Tue, Sep 27, 2016 at 11:05 AM, Craig Ringer wrote: > On 26 September 2016 at 21:52, Vladimir Gordiychuk wrote: >>>You should rely on time I tests as little as possible. Some of the test >>> hosts are VERY slow. If possible something deterministic

Re: [HACKERS] Stopping logical replication protocol

On 26 September 2016 at 21:52, Vladimir Gordiychuk wrote: >>You should rely on time I tests as little as possible. Some of the test >> hosts are VERY slow. If possible something deterministic should be used. > > That's why this changes difficult to verify. Maybe in that case we

Re: [HACKERS] Stopping logical replication protocol

>You should rely on time I tests as little as possible. Some of the test hosts are VERY slow. If possible something deterministic should be used. That's why this changes difficult to verify. Maybe in that case we should write benchmark but not integration test? In that case we can say, before

Re: [HACKERS] Stopping logical replication protocol

On 26 Sep. 2016 02:16, "Vladimir Gordiychuk" wrote: > > >It looks like you didn't import my updated patches, so I've rebased your new patches on top of them. > Yes, i forgot it, sorry. Thanks for you fixes. > > >I did't see you explain why this was removed: > > -/* fast path

Re: [HACKERS] Stopping logical replication protocol

>It looks like you didn't import my updated patches, so I've rebased your new patches on top of them. Yes, i forgot it, sorry. Thanks for you fixes. >I did't see you explain why this was removed: -/* fast path */ -/* Try to flush pending output to the client */ -if

Re: [HACKERS] Stopping logical replication protocol

On 19 September 2016 at 07:12, Vladimir Gordiychuk wrote: > New patch in attach. 0001 and 0002 without changes. > 0003 - patch contain improvements for pg_recvloginca, now pg_recvloginca > after receive SIGINT will send CopyDone package to postgresql and wait from > server

Re: [HACKERS] Stopping logical replication protocol

New patch in attach. 0001 and 0002 without changes. 0003 - patch contain improvements for pg_recvloginca, now pg_recvloginca after receive SIGINT will send CopyDone package to postgresql and wait from server CopyDone. For backward compatible after repeat send SIGINT pg_recvloginca will continue

Re: [HACKERS] Stopping logical replication protocol

>Have you had a chance to look at adding the tests we discussed? Not yet. I plane do it on this weekends 2016-09-16 4:37 GMT+03:00 Craig Ringer : > On 9 September 2016 at 12:03, Craig Ringer wrote: > > > Setting "waiting on author" in CF per

Re: [HACKERS] Stopping logical replication protocol

On 9 September 2016 at 12:03, Craig Ringer wrote: > Setting "waiting on author" in CF per discussion of the need for tests. Have you had a chance to look at adding the tests we discussed? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Stopping logical replication protocol

On 9 September 2016 at 10:37, Craig Ringer wrote: > I'm looking at the revised patch now. Considerably improved. I fixed a typo from decondig to decoding that's throughout all the callback names. This test is wrong: +while ((change =

Re: [HACKERS] Stopping logical replication protocol

On Fri, Sep 9, 2016 at 11:37 AM, Craig Ringer wrote: > When writing TAP tests for Perl you must ensure you use only Perl > 5.8.8-compatible code and only the core modules plus IPC::Run . You'll > usually be fine if you just avoid importing things you don't see other >

Re: [HACKERS] Stopping logical replication protocol

On 9 September 2016 at 03:56, Vladimir Gordiychuk wrote: >>It'd helpful if you summarize the changes made when posting revisions. > > Can we use as summary about changes first message? I meant "what did you change between the last patch I posted and the one you just posted" ?

Re: [HACKERS] Stopping logical replication protocol

>It'd helpful if you summarize the changes made when posting revisions. Can we use as summary about changes first message? If not, summary can be something like that: This parches fix scenarios interrupt logical replication from client side and allow the client to end a logical decoding session

Re: [HACKERS] Stopping logical replication protocol

On 7 September 2016 at 15:44, Vladimir Gordiychuk wrote: > Fixed patch in attach. It'd helpful if you summarize the changes made when posting revisions. >> * There are no tests. I don't see any really simple way to test this, >> though. > > I will be grateful if you specify

Re: [HACKERS] Stopping logical replication protocol

>Review comments on the 2nd patch, i.e. the 2nd half of your original patch: > >* Other places in logical decoding use the CB suffix for callback >types. This should do the same. > >* I'm not too keen on the name is_active for the callback. We >discussed the name continue_decoding_cb in our prior

Re: [HACKERS] Stopping logical replication protocol

On 25 August 2016 at 13:04, Craig Ringer wrote: > By the way, I now think that the second part of your patch, to allow > interruption during ReorderBufferCommit processing, is also very > desirable. I've updated your patch, rebasing it on top of 10.0 master and splitting

Re: [HACKERS] Stopping logical replication protocol

On 25 August 2016 at 09:22, Craig Ringer wrote: > On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote: >> Hi. It has already passed a few months but patch still have required review >> state. Can I help to speed up the review, or should i wait

Re: [HACKERS] Stopping logical replication protocol

On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote: > Hi. It has already passed a few months but patch still have required review > state. Can I help to speed up the review, or should i wait commitfest? > I plane complete changes in pgjdbc drive inside PR >

Re: [HACKERS] Stopping logical replication protocol

Hi. It has already passed a few months but patch still have required review state. Can I help to speed up the review, or should i wait commitfest? I plane complete changes in pgjdbc drive inside PR https://github.com/pgjdbc/pgjdbc/pull/550 but PR blocked current problem with not available stop

Re: [HACKERS] Stopping logical replication protocol

On 11 May 2016 at 06:47, Vladimir Gordiychuk wrote: > Same thread, I just think these are two somewhat separate changes. One is >> just in the walsender and allows return to command mode during waiting for >> WAL. The other is more intrusive into the reorder buffer etc and

Re: [HACKERS] Stopping logical replication protocol

> > Same thread, I just think these are two somewhat separate changes. One is > just in the walsender and allows return to command mode during waiting for > WAL. The other is more intrusive into the reorder buffer etc and allows > aborting decoding during commit processing. So two separate patches

Re: [HACKERS] Stopping logical replication protocol

On 11 May 2016 at 01:15, Vladimir Gordiychuk wrote: > in which release can be include first part? > Since it's not a bug fix, I don't think it can go in before 9.7. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: [HACKERS] Stopping logical replication protocol

in which release can be include first part? 2016-05-10 15:15 GMT+03:00 Craig Ringer : > On 10 May 2016 at 19:41, Vladimir Gordiychuk wrote: > >> >> Fair enough. Though I don't understand why you'd be doing this often >>> enough that you'd care about

Re: [HACKERS] Stopping logical replication protocol

On 10 May 2016 at 19:41, Vladimir Gordiychuk wrote: > > Fair enough. Though I don't understand why you'd be doing this often >> enough that you'd care about reopening connections. What is the problem you >> are trying to solve with this? The underlying reason you need this

Re: [HACKERS] Stopping logical replication protocol

> Fair enough. Though I don't understand why you'd be doing this often > enough that you'd care about reopening connections. What is the problem you > are trying to solve with this? The underlying reason you need this change? > First reason it clear API in pgjdc. Second reason it ability fast

Re: [HACKERS] Stopping logical replication protocol

On 10 May 2016 at 09:50, Craig Ringer wrote: > I outlined how I think WalSndWaitForWal() should be handled earlier. Test > streamingDoneReceiving > and streamingDoneSending in logical_read_xlog_page and return -1. > OK, so thinking about this some more, I see why you've

Re: [HACKERS] Stopping logical replication protocol

> > ProcessRepliesIfAny also now executes in WalSdnWriteData. Because during > send data we should also check message from client(client can send > CopyDone, KeepAlive, Terminate). > > Ah, I didn't spot that ProcessRepliesIfAny() is already called from WalSndWriteData in the current codebase. I

Re: [HACKERS] Stopping logical replication protocol

> > What's your PostgreSQL community username? gordiychuk It seems like what you're also trying to allow interruption deeper than > that, when we're in the middle of processing a reorder buffer commit record > and streaming that to the client. You're introducing an is_active member > (actually a

Re: [HACKERS] Stopping logical replication protocol

I've created a CF entry for this patch: https://commitfest.postgresql.org/10/621/ set as waiting-on-author. Vladimir, I didn't find a PostgreSQL community user account for you, so I couldn't set you up as the author. What's your PostgreSQL community username?

Re: [HACKERS] Stopping logical replication protocol

On 6 May 2016 at 23:23, Vladimir Gordiychuk wrote: > I prepare small patch that fix problems describe below. Now *WalSndWriteData > *first check message from consumer and during decode transaction check > that replication still active. > OK, upon looking closer I'm not sure I

Re: [HACKERS] Stopping logical replication protocol

On 6 May 2016 at 23:23, Vladimir Gordiychuk wrote: > I prepare small patch that fix problems describe below. Now *WalSndWriteData > *first check message from consumer and during decode transaction check > that replication still active. KeppAlive message now not send if was get

Re: [HACKERS] Stopping logical replication protocol

Replication work via Copy API, so for stop replication walcender.c wait CopyDone. My communication seems like this FE=> StartReplication(query: START_REPLICATION SLOT pgjdbc_logical_replication_slot LOGICAL 0/18FCFD0 ("include-xids" 'false', "skip-empty-xacts" 'true')) FE=> Query(CopyStart) <=BE

Re: [HACKERS] Stopping logical replication protocol

On Fri, May 6, 2016 at 5:23 PM, Vladimir Gordiychuk wrote: > Hi all, > > During implementing logical replication protocol for pgjdbc > https://github.com/pgjdbc/pgjdbc/pull/550 I faced with strange behavior > of the *walcender.c*: > >1. When WAL consumer catchup master and