From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming Replication on win32 |
Date: | 2010-01-18 09:40:11 |
Message-ID: | 9837222c1001180140q6ca9d49eia1a80da0f2808f5e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 18, 2010 at 10:30, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Mon, Jan 18, 2010 at 5:22 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-01-18 10:02:29 | Re: Clearing global statistics |
Previous Message | Fujii Masao | 2010-01-18 09:35:01 | Re: Hot Standby and handling max_standby_delay |