X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 86C149DC84B
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Sun,  8 Jan 2006 12:49:22 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 31447-10
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Sun,  8 Jan 2006 12:49:21 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227])
	by postgresql.org (Postfix) with ESMTP id EE0849DC827
	for <pgsql-hackers@postgresql.org>;
	Sun,  8 Jan 2006 12:49:19 -0400 (AST)
Received: from localhost ([127.0.0.1] helo=stark.xeocode.com)
	by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian))
	id 1EvdjF-0005JU-00; Sun, 08 Jan 2006 11:49:13 -0500
To: Hannu Krosing <hannu@skype.net>
Cc: Simon Riggs <simon@2ndquadrant.com>,  Tom Lane <tgl@sss.pgh.pa.us>,
	Qingqing Zhou <zhouqq@cs.toronto.edu>,  pgsql-hackers@postgresql.org
Subject: Re: Stats collector performance improvement
References: <200601021840.k02Ieed21704@candle.pha.pa.us>
	<11924.1136233224@sss.pgh.pa.us> <dpc4cg$lm6$1@news.hub.org>
	<12503.1136238525@sss.pgh.pa.us>
	<1136281253.5052.113.camel@localhost.localdomain>
	<1136324574.4256.17.camel@localhost.localdomain>
In-Reply-To: <1136324574.4256.17.camel@localhost.localdomain>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 08 Jan 2006 11:49:12 -0500
Message-ID: <87wtha1x87.fsf@stark.xeocode.com>
Lines: 15
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.115 required=5 tests=[AWL=0.115]
X-Spam-Score: 0.115
X-Spam-Level: 
X-Archive-Number: 200601/262
X-Sequence-Number: 78366


Hannu Krosing <hannu@skype.net> writes:

> Interestingly I use pg_stat_activity view to watch for stuck backends,
> "stuck" in the sense that they have not noticed when client want away
> and are now waitin the TCP timeout to happen. I query for backends which
> have been in "<IDLE>" state for longer than XX seconds. I guess that at
> least some kind of indication for this should be available.

You mean like the tcp_keepalives_idle option?

http://www.postgresql.org/docs/8.1/interactive/runtime-config-connection.html#GUC-TCP-KEEPALIVES-IDLE

-- 
greg