Re: libpq SSL with non-blocking sockets

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Steve Singer <ssinger_pg(at)sympatico(dot)ca>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq SSL with non-blocking sockets
Date: 2011-07-24 16:22:25
Message-ID: 13077.1311524545@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martin Pihlak <martin(dot)pihlak(at)gmail(dot)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(at)openssl(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-07-24 16:45:35 Re: libpq SSL with non-blocking sockets
Previous Message Tom Lane 2011-07-24 15:55:04 Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)