Horton

Re: libpq SSL with non-blocking sockets

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Martin Pihlak <martin.pihlak@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Steve Singer <ssinger_pg@sympatico.ca>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2011-07-24T16:22:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve libpq's error reporting for SSL failures.

  2. Use OpenSSL's SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag.

Martin Pihlak <martin.pihlak@gmail.com> writes:
> On 07/16/2011 12:46 AM, Tom Lane wrote:
>> I think the direction to move in ought to be to use the existing buffer
>> as-is, and have pqCheckOutBufferSpace refuse to enlarge the buffer while
>> we are in "write frozen" state.  It should be OK to append data to the
>> buffer, though, so long as we remember how much we're allowed to pass to
>> SSL_write when we next try to write.

> Alternative to freezing the outBuffer would be to set
> SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER mode during SSL initialisation.

Hmmm ... that is a really interesting flag.  The documentation is
inadequate, but I googled a bit and found this thread about it:
http://www.mail-archive.com/openssl-users@openssl.org/msg45440.html
in which it's stated that (1) the prohibition on moving the buffer is
actually just a sort of sanity check, and can be turned off using this
flag; (2) it is okay to increase, but not reduce, the length parameter
to SSL_write in the next call after a WANT_READ/WANT_WRITE return.

So this does look like it'd fix the issue for SSL_write, without needing
to introduce a concept of a "write frozen" buffer state.  I am wondering
though how far back support for this flag exists in OpenSSL, and whether
the situation is the same for SSL_read or not.  I don't see any
SSL_MODE_ACCEPT_MOVING_READ_BUFFER macro ...

			regards, tom lane