Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 755AE64FD40 for ; Mon, 29 Dec 2008 04:06:59 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 93933-09-2 for ; Mon, 29 Dec 2008 04:06:56 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from shopzeus.com (135-shost.hostoffice.hu [195.228.74.135]) by mail.postgresql.org (Postfix) with ESMTP id EF94E64FD7A for ; Mon, 29 Dec 2008 04:06:55 -0400 (AST) Received: from [192.168.1.104] (localhost [127.0.0.1]) by shopzeus.com (Postfix) with ESMTP id BC26539243F; Mon, 29 Dec 2008 02:57:53 -0500 (EST) Message-ID: <4958851B.8060500@shopzeus.com> Date: Mon, 29 Dec 2008 09:06:51 +0100 From: Laszlo Nagy User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Tom Lane , pgsql-admin@postgresql.org Subject: Re: rebellious pg stats collector (reopened case) References: <49479876.8040607@shopzeus.com> <20081216134542.GH4741@alvh.no-ip.org> <494B614C.5060808@shopzeus.com> <20081219130446.GC4278@alvh.no-ip.org> <494F67D2.3090406@shopzeus.com> <6938.1229952228@sss.pgh.pa.us> <20081222132721.GC10220@alvh.no-ip.org> <7117.1229952970@sss.pgh.pa.us> In-Reply-To: <7117.1229952970@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.125 tagged_above=0 required=5 tests=DNS_FROM_RFC_BOGUSMX=2.125 X-Spam-Level: ** X-Archive-Number: 200812/191 X-Sequence-Number: 31024 Tom Lane wrote: > Alvaro Herrera writes: > >> Tom Lane wrote: >> >>> I wonder whether your tracing tool is affecting the result of >>> getppid(). Most people would consider that a bug in the tracing tool. >>> > > I wrote to an official the FreeBSD list about this getppid() problem but got no answer other than that "this behaviour is documented". :-( The problem is still there: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11205 pgsql 1 104 0 22400K 7112K CPU5 5 159.7H 99.02% postgres 100% CPU since 159 hours! What can I do? Instead of tracing system calls, is there a way to start the stats collector in debug mode? Or maybe is it possible to change the source code, and disable the "is postmaster alive" check for testing? Thanks