Fix connecting to backend problem introduced in 3.2 due to using non-blocking socket reported in bug #46 and [pgpool-general: 1218] (http://www.pgpool.net/pipermail/pgpool-general/2012-December/001237.html). The problem reported in [pgpool-general: 1218] was that the function treats EISCONN of connect(2) as an error (error message is "Socket is already connected"). We should treat this as normal and it has already been fixed in master and 3.2-stable in commit http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=eb310fca19fbf700e9d83029f18673bc1a308f9a in December 5, 2012. However this was not enough fix for #46. Despite the errors like "Connection timed out", actually connection has been established:
Fix connecting to backend problem introduced in 3.2 due to using
non-blocking socket reported in bug #46 and [pgpool-general: 1218]
(http://www.pgpool.net/pipermail/pgpool-general/2012-December/001237.html).
The problem reported in [pgpool-general: 1218] was that the function
treats EISCONN of connect(2) as an error (error message is "Socket is
already connected"). We should treat this as normal and it has already
been fixed in master and 3.2-stable in commit
http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=eb310fca19fbf700e9d83029f18673bc1a308f9a
in December 5, 2012.
However this was not enough fix for #46. Despite the errors like
"Connection timed out", actually connection has been established:

> Nov 22 11:55:22 fantomas1 pgpool[30351]: connect_inet_domain_socket: connect() failed: Connection timed out
> Nov 22 11:55:22 fantomas1 pgpool[30351]: connection to fantomas4.prod.extelia.fr(5432) failed
> Nov 22 11:55:22 fantomas1 pgpool[30351]: new_connection: create_cp() failed
> Nov 22 11:55:22 fantomas1 pgpool[30351]: degenerate_backend_set: 1 fail over request from pid 30351
>
> A tcpdump from the same period shows that the connection has been established.

To solve the problem we should use select(2) to wait for connection
establishing when connect(2) reports EINPROGRESS or EALREADY, instead
of doing a retry tight loop. If those errors were reported, we issue
select(2) expecting read or write for the socket is set. The strange
part of the technique is, if both read and write were set, it
indicates *either* success or error. See the code magic and comment.

Back patch to 3.2-stable.

treasure-data/prestogres,treasure-data/prestogres,treasure-data/prestogres,treasure-data/prestogres,treasure-data/prestogres,treasure-data/prestogres,treasure-data/prestogres