Re: Stopping logical replication protocol
От | Vladimir Gordiychuk |
---|---|
Тема | Re: Stopping logical replication protocol |
Дата | |
Msg-id | CAFgjRd3Lc86PVifvy80=ugyF3gZQ7RqamhKkEtsRxC7JBpKQNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Stopping logical replication protocol (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Stopping logical replication protocol
(Craig Ringer <craig@2ndquadrant.com>)
|
Список | pgsql-hackers |
>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.
Sounds good. Is it changes should be include in this PR? I'm not ensure that I do this before complete this commitefest, I need some time to understand how this tests works, and how can i write new one.
On 7 September 2016 at 15:44, Vladimir Gordiychuk <folyga@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# testDuringSendBigTransactionRe plicationStreamCloseNotActive
> org.postgresql.replication.LogicalReplicationTest# testAfterCloseReplicationStrea mDBSlotStatusNotActive 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
В списке pgsql-hackers по дате отправления: