Re: libpq SSL with non-blocking sockets

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 />