Re: Streaming Replication on win32
От | Magnus Hagander |
---|---|
Тема | Re: Streaming Replication on win32 |
Дата | |
Msg-id | 9837222c1001180140q6ca9d49eia1a80da0f2808f5e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming Replication on win32 (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Streaming Replication on win32
|
Список | pgsql-hackers |
On Mon, Jan 18, 2010 at 10:30, Fujii Masao <masao.fujii@gmail.com> wrote: > On Mon, Jan 18, 2010 at 5:22 AM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >>> This could be because the win32 socket emulation layer simply wasn't >>> designed to deal with non-blocking sockets. Specifically, it actually >>> *always* sets the socket to non-blocking mode, and then uses that to >>> properly emulate how sockets work under unix. >> >> I presume the win32 emulation layer can be taught about non-blocking >> sockets? Or maybe pq_getbyte_if_available() can be implemented using >> some other simpler method on Windows. > > How about checking the socket by using select/poll before calling > pq_getbyte_if_available()? This would prevent pgwin32_recv() from > being blocked because a message is guaranteed to have already arrived. > When the renegotiation happens, SSL_read (instead of pqwin32_recv()) > is called with non-blocking socket, so it's not blocked. SSL_read calls into pqwin32_recv(), so you have the same problem. (see my_sock_read() and my_sock_write() in be-secure.c) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: