From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com> |
Cc: | Ryan Kelly <rpkelly22(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Allow breaking out of hung connection attempts |
Date: | 2012-07-12 13:28:41 |
Message-ID: | 4FFED109.7030203@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09.07.2012 11:35, Shigeru HANADA wrote:
> Once the issues above are fixed, IMO this patch can be marked as "Ready
> for committer".
Thanks. The docs on async connections says:
"The connect_timeout connection parameter is ignored when using
PQconnectPoll; it is the application's responsibility to decide whether
an excessive amount of time has elapsed."
I think we should recommend using PQconnectTimeout(), similar to what
you did in psql, in all client applications that use the non-blocking
connection API. Perhaps something like:
"The connect_timeout connection parameter is ignored when using
PQconnectPoll; it is the application's responsibility to decide whether
an excessive amount of time has elapsed. It is recommended to use the
PQconnectTimeout() to get value of the parameter, and use that as the
timeout in the application. That way the user gets the same timeout
behavior, regardless of whether the application uses PQconnectPoll or
the nonblocking connection API."
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2012-07-12 13:57:36 | Re: Schema version management |
Previous Message | Tom Lane | 2012-07-12 13:24:48 | Re: Schema version management |