From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(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:14:44 |
Message-ID: | 4B4F0AB4.4010306@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
See that in my git repository. Attached is a new version of the whole
streaming replication patch, for the benefit of archives and git non-users.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
sr-20100114.patch.gz | application/x-gzip | 47.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-01-14 12:21:07 | Re: Hot Standby and query cancel |
Previous Message | Simon Riggs | 2010-01-14 11:27:42 | Re: Small Bug in GetConflictingVirtualXIDs |