On Mon, Dec 6, 2010 at 3:07 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> The one time this year top-posting seems appropriate...this patch seems
> stalled waiting for some sort of response to the concerns Alvaro raised
> here.
Sorry for the delay. I didn't have the time.
> I gave this a look. It seems good, but I'm not sure about this bit:
Thanks for the review!
> I guess this was OK when this was conceived as CopyXlog, but since it's
> now a generic mechanism, this seems a bit unwise. Should this be
> reconsidered so that it's possible to change the format or number of
> columns?
I changed CopyBothResponse message so that it includes the format
and number of columns of copy data. Please see the attached patch.
> (The paragraph added to the docs is also a bit too specific about this
> being used exclusively in streaming replication, ISTM)
Yes. But it seems difficult to generalize the docs more because currently
only SR uses Copy-both. So I had to write that, for example, the condition
to get into the state is only "START REPLICATION" command.
> While modifying the code, it occurred to me that we might have to add new
> ExecStatusType like PGRES_COPY_BOTH and use that for CopyBoth mode,
> for the sake of consistency. But since it's just alias of PGRES_COPY_BOTH
> for now, i.e., there is no specific behavior for that ExecStatusType, I
> don't
> think that it's worth adding that yet.
>
>
> I'm not so sure about this. If we think that it's worth adding a new
> possible state, we should do so now; we will not be able to change this
> behavior later.
OK. I added that new state.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center