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

From Oleksandr Shulgin
Subject Re: Stopping logical replication protocol
Date
Msg-id CACACo5Q2nKimxm6JPMGBJOu2fpcPdaR6APptT9XyH1WvJyEJHA@mail.gmail.com
Whole thread Raw
In response to Stopping logical replication protocol  (Vladimir Gordiychuk <folyga@gmail.com>)
Responses Re: Stopping logical replication protocol  (Vladimir Gordiychuk <folyga@gmail.com>)
List pgsql-hackers
On Fri, May 6, 2016 at 5:23 PM, Vladimir Gordiychuk <folyga@gmail.com> wrote:
Hi all,

During implementing logical replication protocol for pgjdbc https://github.com/pgjdbc/pgjdbc/pull/550 I faced with strange behavior of the walcender.c:
  1. When WAL consumer catchup master and change his state to streaming, not available normally complete replication by send CopyDone message until will not generate/create new WAL record. It occurs because logical decoding located in WalSndWaitForWal until will not available next WAL record, and it method receive message from consumer even reply on CopyDone with CopyDone but ignore exit from loop and we can wait many times waiting CommandStatus & ReadyForQuery packages on consumer.
  2. Logical decoding ignore message from consumer during decoding and writing transaction in socket(WalSndWriteData). It affect long transactions with many changes. Because for example if we start decoding transaction that insert 1 million records and after consume 1% of it date we
    decide stop replication, it will be not available until whole million record will not send to consumer.
How exactly are you stopping the replication?  If you just stop reading you'll likely to hit some problems, but what if you also close the connection?  I don't think there is any other supported way to do it.

I was working last year on adding support for replication protocol to the Python driver: https://github.com/psycopg/psycopg2/pull/322   It would be nice if you could skim through this implementation, since it didn't receive a whole lot of review.

Cheers.
--
Alex

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Poorly-thought-out handling of double variables in pgbench
Next
From: Tom Lane
Date:
Subject: Re: Poorly-thought-out handling of double variables in pgbench