On 11-06-15 03:20 PM, Martin Pihlak wrote: <blockquote cite="mid:4DF90602.7060201@gmail.com" type="cite"><br /><pre
wrap="">
Yes, that sounds like a good idea -- especially considering that COPY
is not the only operation that can cause SSL_write retries.
This is of course still "work in progress", needs cleaning up and
definitely more testing. But at this point before going any further,
I'd really appreciate a quick review from resident libpq gurus.
</pre></blockquote><br /> Martin, <br /><br /> I'm not a libpq guru but I've given your patch a look over.<br /><br />
Theidea of storing the original buffer in new members of connection structure for later re-use seems like a good way to
approachthis. <br /><br /> A few things I noticed (that you might be aware of since you mentioned it needs cleanup)<br
/><br/> -The patch doesn't compile with non-ssl builds, the debug at the bottom of PQSendSome isn't in an #ifdef<br
/><br/> -I don't think your handling the return code properly. Consider this case.<br /><br /> pqSendSome(some
data)<br/> sslRetryBuf = some Data<br /> return 1<br /> pqSendSome(more data)<br /> it sends all of 'some
data'<br/> returns 0 <br /><br /> I think 1 should be returned because all of 'more data' still needs to be sent. I
thinkreturning a 0 will break PQsetnonblocking if you call it when there is data in both sslRetryBuf and
outputBuffer.<br/> We might even want to try sending the data in outputBuffer after we've sent all the data sitting in
sslRetryBuf.<br/><br /><br /> If you close the connection with an outstanding sslRetryBuf you need to free it.<br /><br
/><br/> Other than running your test program I didn't do any testing with this patch.<br /><br /> Steve<br /><br
/><blockquotecite="mid:4DF90602.7060201@gmail.com" type="cite"><pre wrap="">regards,
Martin
</pre> <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
</pre></blockquote><br />