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
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) |