| 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 17:10:36 |
| Message-ID: | 13973.1311527436@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Still wondering about the SSL_read end of it, though.
And on that front, some digging around in the OpenSSL source code
indicates that they do all their work in internal buffers, and transfer
data into SSL_read's result buffer only when ready to return it.
So the claim in the documentation that SSL_read has a restriction
comparable to SSL_write is a lie: there is no case where they'll copy
some data into the buffer and then return -1.
So the SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER solution looks like a good
fix. I'll see about applying it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Pflug | 2011-07-24 17:51:27 | Re: XPATH vs. server_encoding != UTF-8 |
| Previous Message | Tom Lane | 2011-07-24 16:45:35 | Re: libpq SSL with non-blocking sockets |