Skip site navigation (1) Skip section navigation (2)

Re: libpq changes for synchronous replication

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq changes for synchronous replication
Date: 2010-09-29 06:53:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Sep 21, 2010 at 1:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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.


Fujii Masao
NTT Open Source Software Center

Attachment: libpqrcv_send_v2.patch
Description: application/octet-stream (10.1 KB)

In response to

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-09-29 07:14:45
Subject: Re: recovery.conf location
Previous:From: Greg SmithDate: 2010-09-29 06:44:35
Subject: Re: ask for review of MERGE

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group