Re: rebellious pg stats collector (reopened case)

From: Laszlo Nagy <gandalf(at)shopzeus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin(at)postgresql(dot)org
Subject: Re: rebellious pg stats collector (reopened case)
Date: 2008-12-29 08:06:51
Message-ID: 4958851B.8060500@shopzeus.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-performance

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2008-12-29 15:26:33 Re: rebellious pg stats collector (reopened case)
Previous Message Raj Mathur 2008-12-27 02:36:55 [DOCUMENT] Migrating Oracle to PostgresSQL

Browse pgsql-performance by date

  From Date Subject
Next Message Laszlo Nagy 2008-12-29 09:43:42 Re: Slow table update
Previous Message Ted Allen 2008-12-29 03:11:47 Re: Troubles dumping a very large table.