On 2015-02-11 14:54:03 +0200, Heikki Linnakangas wrote: > Thoughts? Can you reproduce any errors with this?
I'm on battery right now, so I can't really test much. Did you test having an actual standby instead of pg_receivexlog? I saw some slightly different errors there. Does this patch alone work for you or did you test it together with the earlier one to fix the renegotiation handling server side when nonblocking? Because that frequently seemed to error out for me, at least over actual network. A latch loop + checking for the states seemed to fix that for me. I'm pretty darn happy that you seem to have found a much less ugly solution than mine. Although it's only pretty by comparison ;) > + /* > + * To work-around an issue with OpenSSL and renegotiation, we don't > + * let SSL_write() to read any incoming data. superflous "to". > + * NB: This relies on the calling code to call pqsecure_read(), > completing > + * the renegotiation handshake, if pqsecure_write() returns 0. Otherwise > + * we'll never make progress. > + */ I think this should a) refer to the fact that pqSendSome does that in blocking scenarios b) expand the comment around the pqReadData to reference that fact. How are we going to deal with callers using libpq in nonblocking mode. A client doing a large COPY FROM STDIN to the server using a nonblocking connection (not a stupid thing to do) could hit this IIUC. Could we perhaps call SSL_peek() when SSL_write() hits WANTS_READ? In combination with your fix I think that should fix the possibility of such a deadlock? Especially on the serverside where the socket most of the time is is in, although emulated, blocking mode that seems easier - we can just retry afterwards. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers