Re: libpq changes for synchronous replication

The one time this year top-posting seems appropriate...this patch seems stalled waiting for some sort of response to
theconcerns Alvaro raised here.<br /><br /> Alvaro Herrera wrote: <blockquote
cite="mid:1290818506-sup-5440@alvh.no-ip.org"type="cite"><pre wrap="">Excerpts from Fujii Masao's message of jue nov 25
10:47:12-0300 2010:
 
 </pre><blockquote type="cite"><pre wrap="">The attached patch s/CopyXLog/CopyBoth/g and adds the description
about CopyBoth into the COPY section.   </pre></blockquote><pre wrap="">
I gave this a look.  It seems good, but I'm not sure about this bit:

+               case 'W':       /* Start Copy Both */
+                   /*
+                    * We don't need to use getCopyStart here since CopyBothResponse
+                    * specifies neither the copy format nor the number of columns in
+                    * the Copy data. They should be always zero.
+                    */
+                   conn->result = PQmakeEmptyPGresult(conn, PGRES_COPY_OUT);
+                   if (!conn->result)
+                       return;
+                   conn->asyncStatus = PGASYNC_COPY_BOTH;
+                   conn->copy_already_done = 0;
+                   break;

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?

(The paragraph added to the docs is also a bit too specific about this
being used exclusively in streaming replication, ISTM)
 </pre><blockquote type="cite"><pre wrap="">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.   </pre></blockquote><pre wrap="">
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. </pre></blockquote><br />