Re: [HACKERS] TCP keepalive support for libpq

[Tollef Fog Heen]

]] daveg 

| I disagree. I have clients who have problems with leftover client connections
| due to server host failures. They do not write apps in C. For a non-default
| change to be effective we would need to have all the client drivers, eg JDBC,
| psycopg, DBD-DBI, and the apps like psql make changes to turn it on. Adding
| this option as a non-default will not really help.

FWIW, this is my case.  My application uses psycopg, which provides no
way to get access to the underlying socket.  Sure, I could hack my way
around this, but from the application writer's point of view, I have a
connection that I expect to stay around and be reliable.  Whether that
connection is over a UNIX socket, a TCP socket or something else is
something I would rather not have to worry about; it feels very much
like an abstraction violation.

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] TCP keepalive support for libpq

[Tollef Fog Heen]

]] Robert Haas 

| I've sometimes wondered why keepalives aren't the default for all TCP
| connections.  They seem like they're usually a Good Thing (TM), but I
| wonder if we can think of any situations where someone might not want
| them?

As somebody mentioned somewhere else (I think): If you pay per byte
transmitted, be it 3G/GPRS.  Or if you're on a very, very high-latency
link or have no bandwidth.  Like, a rocket to Mars or maybe the moon.
While I think they are valid use-cases, requiring people to change the
defaults if that kind of thing sounds like a sensible solution to me.

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] TCP keepalive support for libpq

[Tollef Fog Heen]

(please Cc me on replies, I am not subscribed)

Hi,

libpq currently does not use TCP keepalives.  This is a problem in our
case where we have some clients waiting for notifies and then the
connection is dropped on the server side.  The client never gets the FIN
and thinks the connection is up.  The attached patch unconditionally
adds keepalives.  I chose unconditionally as this is what the server
does.  We didn't need the ability to tune the timeouts, but that could
be added with reasonable ease.

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are
*** a/src/interfaces/libpq/fe-connect.c
--- b/src/interfaces/libpq/fe-connect.c
***
*** 1321,1326  keep_going:		/* We will come back to here until there is
--- 1321,1338 
  		continue;
  	}
  #endif   /* F_SETFD */
+ 	optval = 1;
+ 	if (setsockopt(conn-sock, SOL_SOCKET, SO_KEEPALIVE,
+ 		   (char *) optval, sizeof(optval)) == -1)
+ 	{
+ 		appendPQExpBuffer(conn-errorMessage,
+ 		  libpq_gettext(could not set keepalive on socket: %s\n),
+ 			SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
+ 		closesocket(conn-sock);
+ 		conn-sock = -1;
+ 		conn-addr_cur = addr_cur-ai_next;
+ 		continue;
+ 	}
  
  	/*--
  	 * We have three methods of blocking SIGPIPE during

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] TCP keepalive support for libpq

[Tollef Fog Heen]

]] Magnus Hagander 

| Seems reasonable to add this. Are there any scenarios where this can
| cause trouble, that would be fixed by having the ability to select
| non-standard behavior?

Well, it might be unwanted if you're on a pay-per-bit connection such as
3G, but in this case, it just makes the problem a bit worse than the
server keepalive already makes it – it doesn't introduce a new problem.

| I don't recall ever changing away from the standard behavior in any of
| my deployments, but that might be platform dependent?

If you were (ab)using postgres as an IPC mechanism, I could see it being
useful, but not in the normal case.

| If not, I think this is small and trivial enough not to have to push
| back for 9.1 ;)

\o/

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers