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

From Vladimir Gordiychuk
Subject Re: Stopping logical replication protocol
Date
Msg-id CAFgjRd0Q98s9_TfDvhPNxSQfiP7RpMWU=Ob7D9eenuDaY+T=_Q@mail.gmail.com
Whole thread Raw
In response to Re: Stopping logical replication protocol  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Stopping logical replication protocol  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
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 make sense here IMO, one on top of the other.

About the second part of the patch. What the reason decode and send whole transaction? Why we can't process logical decoding via WalSndLoop LSN by LSN as it work in physycal replication? For example if transaction contains in more them one LSN, first we decode and send "begin", "part data from current LSN" and then returns to WalSndLoop on the next iteration we send "another part data", "commit". I don't research in this way, because I think it will be big changes in comparison callback that stop sending.

2016-05-10 20:22 GMT+03:00 Craig Ringer <craig@2ndquadrant.com>:
On 11 May 2016 at 01:15, Vladimir Gordiychuk <folyga@gmail.com> 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, Training & Services

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
Next
From: Jeff Janes
Date:
Subject: Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)