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
