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

From Tom Lane
Subject Re: libpq changes for synchronous replication
Date
Msg-id 10890.1289867214@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq changes for synchronous replication  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: libpq changes for synchronous replication
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Sep 20, 2010 at 12:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> This appears to be the only obvious unresolved issue regarding this patch:

> https://commitfest.postgresql.org/action/patch_view?id=412

> I don't have a strong personal position on whether or not we should do
> this, but it strikes me that Tom hasn't given much justification for
> why he thinks we should do this, what benefit we'd get from it, or
> what the design should look like.  So I guess the question is whether
> Tom - or anyone - would like to make a case for a more serious
> protocol overhaul, or whether we should just go with the approach
> proposed here.

I was objecting to v1 of the patch.  v2 seems somewhat cleaner --- it at
least avoids changing the behavior of libpq for normal COPY operation.
I'm still a bit concerned by the prospect of having to shove further
warts into the COPY data path in future, but maybe its premature to
complain about that when it hasn't happened yet.

Just in a quick scan, I don't have any objection to v2 except that the
protocol documentation is lacking.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Fix for seg picksplit function
Next
From: Tom Lane
Date:
Subject: Isn't HANDLE 64 bits on Win64?