On Tue, Apr 24, 2007 at 05:53:02AM -0700, Jeff Lanzarotta wrote:
> Hello,
>
> I am writing an application that reads information from my PostgreSQL
> database. If I cause the program to crash and the program ends without
> gracefully disconnecting from the database, there is an open connection
> still left in the database.
>
> How does the PostgreSQL server handle clients that disconnect
> ungracefully? Will the server automatically clean up this connection
> that really is not there?

Yes, but it will log a notice about it in the server log.

//Magnus


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

OK, thanks. I figured the server would at some point in time clear the
connection up, my question now is when does that happen? Any idea how
long the connection sit around before the server cleans it up? Someone
else said possibly an hour...

--- Magnus Hagander <magnus@hagander.net> wrote:

> On Tue, Apr 24, 2007 at 05:53:02AM -0700, Jeff Lanzarotta wrote:
> > Hello,
> >
> > I am writing an application that reads information from my
> PostgreSQL
> > database. If I cause the program to crash and the program ends
> without
> > gracefully disconnecting from the database, there is an open
> connection
> > still left in the database.
> >
> > How does the PostgreSQL server handle clients that disconnect
> > ungracefully? Will the server automatically clean up this
> connection
> > that really is not there?
>
> Yes, but it will log a notice about it in the server log.
>
> //Magnus
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly
>


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tue, Apr 24, 2007 at 06:55:12AM -0700, Jeff Lanzarotta wrote:
> OK, thanks. I figured the server would at some point in time clear the
> connection up, my question now is when does that happen? Any idea how
> long the connection sit around before the server cleans it up? Someone
> else said possibly an hour...

Depends on yuor OS - when the TCP connection times out, PostgreSQL will
clean up and terminate the backup.

//Magnus


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

OK, that is what the other fellow said... It depends on the TCP/IP
stack...

Thanks again for the clarification.

--- Magnus Hagander <magnus@hagander.net> wrote:

> On Tue, Apr 24, 2007 at 06:55:12AM -0700, Jeff Lanzarotta wrote:
> > OK, thanks. I figured the server would at some point in time clear
> the
> > connection up, my question now is when does that happen? Any idea
> how
> > long the connection sit around before the server cleans it up?
> Someone
> > else said possibly an hour...
>
> Depends on yuor OS - when the TCP connection times out, PostgreSQL
> will
> clean up and terminate the backup.
>
> //Magnus
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Tue, Apr 24, 2007 at 07:16:38AM -0700, Jeff Lanzarotta wrote:
> OK, that is what the other fellow said... It depends on the TCP/IP
> stack...
>
> Thanks again for the clarification.

Note, there are two cases. If only the program crashes but the system
is fine, the kernel will close the socket for you straight away and the
server with notice the hangup.

The only time the server will wait for a time out is if the server and
the client are on different machines and something disrupts actual
communications. If the client machine crashes without notifying the
server, or someone pulls out a network cable. If the client and the
server are on the same machine, it will always notice.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGLiSWIB7bNG8LQkwRApAFAJ4qC8bbFg7109sT2DwTU8 VmYBAdEQCdGR7Y
+RWGNqBcG2Rw30MB/DSQbzY=
=R0HM
-----END PGP SIGNATURE-----

Martijn van Oosterhout <kleptog@svana.org> writes:
> The only time the server will wait for a time out is if the server and
> the client are on different machines and something disrupts actual
> communications.

Right, you need connectivity loss to create an issue --- a client
program crash doesn't cause this type of problem. The most common
form of the problem that I've heard about is routers deciding to drop a
connection that's been idle too long.

BTW, on some platforms it's possible to change the timeout settings so
that a lost connection is abandoned more quickly by the TCP stack.
See the tcp_keepalives_xxx parameters if you need to do that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match