Re: Stopping logical replication protocol

From: Vladimir Gordiychuk <folyga(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Álvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Stopping logical replication protocol
Date: 2016-09-08 19:56:03
Message-ID: CAFgjRd3Lc86PVifvy80=ugyF3gZQ7RqamhKkEtsRxC7JBpKQNQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)com>:

> On 7 September 2016 at 15:44, Vladimir Gordiychuk <folyga(at)gmail(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2016-09-08 20:06:30 Re: sequence data type
Previous Message Tom Lane 2016-09-08 19:46:46 Re: Is tuplesort_heap_siftup() a misnomer?