On Fri, Apr 6, 2012 at 18:43, Tom Lane wrote:
> Magnus Hagander writes:
>> True. I guess I was just assuming that JDBC (and npgsql i think?) were
>> using TLS - I would assume that to be the default in both Java and
>> .NET. We'd have to check that before making a change of course - and
>> I'm no
Magnus Hagander writes:
> True. I guess I was just assuming that JDBC (and npgsql i think?) were
> using TLS - I would assume that to be the default in both Java and
> .NET. We'd have to check that before making a change of course - and
> I'm not convinced we need to make the change. But if we're
On Fri, Apr 6, 2012 at 02:05, Tom Lane wrote:
> Magnus Hagander writes:
>> If anything, we should be changing it to TLSv1 in both client and
>> server, since every client out there now should be using that anyway,
>> given that the client has been specifying it for a long time.
>
> Huh? libpq is
Magnus Hagander writes:
> If anything, we should be changing it to TLSv1 in both client and
> server, since every client out there now should be using that anyway,
> given that the client has been specifying it for a long time.
Huh? libpq isn't every client.
regards, tom
On Thu, Apr 5, 2012 at 08:00, Tatsuo Ishii wrote:
>>> Those code fragment judges the return value from
>>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
>>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
>>> when SSL_ERROR_WANT_READ. It seems they a
>> Those code fragment judges the return value from
>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
>> when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments?
>
> There's no particular
Magnus Hagander writes:
> On Wed, Apr 4, 2012 at 17:57, Tom Lane wrote:
>> I rather wonder whether the #ifdef WIN32 bit in the backend isn't dead
>> code though. If the port isn't in nonblock mode, we shouldn't really
>> get here at all, should we?
> Not in a position to look at the code right
On Wed, Apr 4, 2012 at 17:57, Tom Lane wrote:
> Tatsuo Ishii writes:
>> Those code fragment judges the return value from
>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
>> when SSL_ERROR_WANT_READ.
Tatsuo Ishii writes:
> Those code fragment judges the return value from
> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
> when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments?
There's
Hi,
While looking into SSL code in secure_read() of be-secure.c and
pqsecure_read() of fe-secure.c, I noticed subtle difference between
them.
In secure_read:
--
case SSL_ERROR_WANT_READ:
case
10 matches
Mail list logo
