> > What about adding KEEPALIVE option to the socket?
>
> Of course, since whatever OS he's using on the client side is too broken
> to notice that the socket is orphaned and close it, it might be so
> broken as to respond to the keepalive pings :-(. Still, it'd be an easy
> thing to try...
>
> Even though the stated case sounds more like an OS bug than anything
> else, setting KEEPALIVE on our TCP connections is probably still a good
> idea. If the client machine were to crash completely then it wouldn't
> be reasonable to expect it to close the connection, and we'd want to
> have some method of ensuring that the connected backend shuts down
> eventually. KEEPALIVE seems sufficiently low-overhead (and easy to
> implement) to be the right answer for this scenario.
Ok. Here are patches against 7.0. BTW, does this break some platforms
such as Windows NT or QUNX4?
*** postgresql-7.0/src/backend/libpq/pqcomm.c.orig Tue May 16 18:06:42 2000
--- postgresql-7.0/src/backend/libpq/pqcomm.c Wed May 17 08:23:09 2000
***************
*** 375,381 **** if (setsockopt(port->sock, pe->p_proto, TCP_NODELAY, &on, sizeof(on)) <
0) {
! perror("postmaster: StreamConnection: setsockopt"); return STATUS_ERROR; } }
--- 375,387 ---- if (setsockopt(port->sock, pe->p_proto, TCP_NODELAY, &on, sizeof(on)) <
0) {
! perror("postmaster: StreamConnection: setsockopt(TCP_NODELAY)");
! return STATUS_ERROR;
! }
! if (setsockopt(port->sock, SOL_SOCKET, SO_KEEPALIVE,
! &on, sizeof(on)) < 0)
! {
! perror("postmaster: StreamConnection: setsockopt(SO_KEEPALIVE)"); return STATUS_ERROR;
} }
