Re: libpq SSL with non-blocking sockets

On Thu, Jun 9, 2011 at 10:39 AM, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> wrote:
> In PQputCopyData #2 it is visible that the first SSL_write called from
> pqFlush failed with SSL_ERROR_WANT_WRITE. The next SSL_write should
> have been a retry with the same parameters, but instead was passed a
> buffer with a different address and length. Hence the "bad write
> retry". Some googling turned out similar issues for other projects
> using SSL with non-blocking sockets.

I'm not surprised. Setting the API so that it requires the same
buffer (and not just a buffer pointing to the same data, or with the
same initial contents) was maybe not the greatest design decision.

> The possible workarounds are to disable SSL or to disable non-blocking
> libpq connections. Both are not always possible - security reasons, 3rd
> party applications, drivers, etc. So I think this should be fixed in
> libpq. Not sure exactly how though. It would seem that for the
> PQputCopyData the best would be to return 0 to indicate that the
> operation should be retried. No idea for the other possible cases of
> SSL_write() retry though. What do you think?

It seems to me we should try to paper over the problem within libpq
rather than allowing it to percolate any higher up the call stack.
One idea is that we could add outBuffer2/outBufSize2 to struct
pg_conn, or something along those lines with less obviously stupid
naming. Normally those would be unused, but in the special case where
SSL indicates that we must retry the call with the same arguments, we
set a flag that "freezes" the out buffer and forces any further data
to be stuffed into outBuffer2. If or when the operation finally
succeeds, we then move the data from outBuffer2 into outBuffer.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company