On 7 September 2016 at 15:44, Vladimir Gordiychuk <fol...@gmail.com> 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 the best way how to do it. I tests this > patches by pgjdbc driver tests that also build on head of postgres. You can > check test scenario for both patches in > PRhttps://github.com/pgjdbc/pgjdbc/pull/550 > > org.postgresql.replication.LogicalReplicationTest#testDuringSendBigTransactionReplicationStreamCloseNotActive > org.postgresql.replication.LogicalReplicationTest#testAfterCloseReplicationStreamDBSlotStatusNotActive Yeah, testing it isn't trivial in postgres core, since of course none of the tools know to send a client-initiated CopyDone. My suggestion is to teach pg_recvlogical to send CopyDone on the first SIGINT (control-C) and wait until the server ends the data-stream and returns to command mode. A second control-C should unilaterally close the connection and it should close after a timeout too. This will be backward compatible with 9.4/5/6 (just with a delay on exit by sigint). Then in a TAP test in src/test/recovery set up a logical decoding session with test_decoding and pg_recvlogical. Do a test xact then sigint pg_recvlogical and verify that it exits. To make sure it exited by mutual agreement with server, probably run pg_recvlogival at a higher debug level and text search for a message you print from pg_recvlogical when it gets server CopyDone in the response to client CopyDone. I don't think a different pg_recvlogical numeric exit code could be justified for this. It sounds like more work than I think it would actually be. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
