Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication and non-blocking I/O

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and non-blocking I/O
Date: 2010-01-14 12:46:07
Message-ID: 3f0b79eb1001140446h47a6e27er87caeee25359bfff@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jan 14, 2010 at 9:14 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> After reading up on SSL_read() and SSL_pending(), it seems that there is
> unfortunately no reliable way of checking if there is incoming data that
> can be read using SSL_read() without blocking, short of putting the
> socket to non-blocking mode. It also seems that we can't rely on poll()
> returning POLLHUP if the remote end has disconnected; it's not doing
> that at least on my laptop.
>
> So, the only solution I can see is to put the socket to non-blocking
> mode. But to keep the change localized, let's switch to non-blocking
> mode only temporarily, just when polling to see if there's data to read
> (or EOF), and switch back immediately afterwards.

Agreed. Though I also read some pages referring to that issue,
I was not able to find any better action other than the temporal
switch of the blocking mode.

> I've added a pq_getbyte_if_available() function to pqcomm.c to do that.
> The API to the upper levels is quite nice, the function returns a byte
> if one is available without blocking. Only minimal changes are required
> elsewhere.

Great! Thanks a lot!

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

pgsql-hackers by date

Next:From: Bernd HelmleDate: 2010-01-14 13:04:46
Subject: Re: Table size does not include toast size
Previous:From: Euler Taveira de OliveiraDate: 2010-01-14 12:42:53
Subject: Re: improving log management

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group