Re: libpq changes for synchronous replication
От | Robert Haas |
---|---|
Тема | Re: libpq changes for synchronous replication |
Дата | |
Msg-id | AANLkTikjCXmatS1i6WUGXoedo8U2Fq68n1U_JVQ2CChP@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: libpq changes for synchronous replication (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: libpq changes for synchronous replication
|
Список | pgsql-hackers |
On Mon, Nov 15, 2010 at 7:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. It's not an unreasonable complaint, but I don't have a very clear idea what to do about it. > Just in a quick scan, I don't have any objection to v2 except that the > protocol documentation is lacking. OK, I'll mark it Waiting on Author pending that issue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: