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
>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 between transactions without just unilaterally closing its connection. The client send CopyDone package and wait stop replication as fast as possible. But in two cases walsender interrupt replication too slow. First scenario it's interrupt during waiting new WAL, when replication in streaming state, walsender ignores messages from Client until new WAL record will not generate. The second scenario it is interrupt replication during decoding long transaction that contain many changes.  

>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.

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. 



2016-09-08 12:29 GMT+03:00 Craig Ringer <craig@2ndquadrant.com>:

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#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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Is tuplesort_heap_siftup() a misnomer?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: sequence data type