Re: Question regarding SSL code in backend and frontend

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question regarding SSL code in backend and frontend
Date: 2012-04-04 15:59:07
Message-ID: CABUevEze=+Hzopv81BEXxZwg2dh2AGc4y71-QDn7MNKVJUG=Lw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 4, 2012 at 17:57, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Tatsuo Ishii <ishii(at)postgresql(dot)org> 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 no particular reason why they should be consistent, I think.
> The assumptions for nonblocking operation are different.
>
> 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 now, but first guess - we
*always* have the underlying socket in nonblocking mode on win32, so
we can deliver signals properly. It becomes blocking only through our
APIs, but the SSL stuff bypasses that in some places - such as this
one calling win32_waitforsinglesocket...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-04-04 16:02:35 Re: invalid search_path complaints
Previous Message Tom Lane 2012-04-04 15:57:10 Re: Question regarding SSL code in backend and frontend