Re: libpq changes for synchronous replication - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: libpq changes for synchronous replication
Date
Msg-id AANLkTin8heAujQMSYeAudp9=JAOyVe6D4DHQ8OetJttm@mail.gmail.com
Whole thread Raw
In response to Re: libpq changes for synchronous replication  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Sep 21, 2010 at 1:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> It doesn't feel right to always accept PQputCopyData in COPY OUT mode,
>> though. IMHO there should be a new COPY IN+OUT mode.
>
> Yeah, I was going to make the same complaint.  Breaking basic
> error-checking functionality in libpq is not very acceptable.
>
>> It should be pretty safe to add a CopyInOutResponse message to the
>> protocol without a protocol version bump. Thoughts on that?
>
> Not if it's something that an existing application might see.  If
> it can only happen in replication mode it's OK.

The attached patch adds a CopyXLogResponse message. The walsender sends
it after processing START_REPLICATION command, instead of CopyOutResponse.
During Copy XLog mode, walreceiver can receive some data from walsender,
and can send some data to walsender.

> Personally I think this demonstrates that piggybacking replication
> data transfer on the COPY protocol was a bad design to start with.
> It's probably time to split them apart.

In the patch, replication data is still transferred on COPY protocol.
If we'd transfer that on dedicated protocol for replication, we would
need to duplicate PQgetCopyData and PQputCopyData and define those
duplicated functions as something like PQgetXLogData and PQputXLogData
for replication.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: ask for review of MERGE
Next
From: Fujii Masao
Date:
Subject: Re: recovery.conf location