Re: Question regarding SSL code in backend and frontend
От | Magnus Hagander |
---|---|
Тема | Re: Question regarding SSL code in backend and frontend |
Дата | |
Msg-id | CABUevEze=+Hzopv81BEXxZwg2dh2AGc4y71-QDn7MNKVJUG=Lw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question regarding SSL code in backend and frontend (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Question regarding SSL code in backend and frontend
|
Список | pgsql-hackers |
On Wed, Apr 4, 2012 at 17:57, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Tatsuo Ishii <ishii@postgresql.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/
В списке pgsql-hackers по дате отправления: