Re: One source of constant annoyance identified

Lists: pgsql-general
From: "Markus Wollny" <Markus(dot)Wollny(at)computec(dot)de>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: One source of constant annoyance identified
Date: 2002-07-03 14:00:27
Message-ID: 2266D0630E43BB4290742247C8910575014CE2CA@dozer.computec.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Hello!

Scanning google for strange backend behaviour of PostgreSQL I stumbled
over the following bug-report:

http://postgresql.linux.cz/mhonarc/pgsql-ports/1999-01/msg00001.html

It's referring to a very old version of PostgreSQL (6.0), but could it
be that we suffer from the very same phenomenon? I do notice "connection
reset by peer" messages in the logfile - I always thought that this
happened when a user terminated his request or a connection broke
because of other (mostly harmless) reasons.

Now to me it seems quite likely that our backends sort of "go to sleep",
too, hogging memory and (for some reason) processing time as well.

Has the mentioned bug report been adressed since then?

Regards,

Markus


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Markus Wollny" <Markus(dot)Wollny(at)computec(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: One source of constant annoyance identified
Date: 2002-07-03 14:37:27
Message-ID: 24622.1025707047@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

"Markus Wollny" <Markus(dot)Wollny(at)computec(dot)de> writes:
> http://postgresql.linux.cz/mhonarc/pgsql-ports/1999-01/msg00001.html
> Has the mentioned bug report been adressed since then?

I don't think it's a bug. TCP is not designed to detect connection
failure instantly, and it's definitely not designed to waste network
resources when neither side of a connection is sending anything.
In the scenario described in the report, the backend is sitting idle
and there's no way to know that the client side thinks the connection
has failed.

In recent releases we set the keepalive feature on, which means that
after a sufficiently long timeout the server side will probe to see
if the client is still there, and will then discover that the
connection is dead. Whereupon the backend will receive a kernel
error report and will exit. But up to that moment, there's no reason
to think that anything is wrong.

regards, tom lane