To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Laszlo Nagy <gandalf@shopzeus.com>, pgsql-admin@postgresql.org
Subject: Re: rebellious pg stats collector (reopened case) 
In-reply-to: <20081222132721.GC10220@alvh.no-ip.org> 
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>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Mon, 22 Dec 2008 10:27:21 -0300"
Date: Mon, 22 Dec 2008 08:36:10 -0500
Message-ID: <7117.1229952970@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alvaro Herrera <alvherre@commandprompt.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.

> Probably having a close look at the PPID column in ps or top during the
> truss run would prove this.

It's at least conceivable that the result being returned inside the
process is different from what the rest of the world sees.  What'd prove
this one way or the other is to write a trivial test program along the
lines of

	while(1) {
		sleep(1);
		printf("ppid = %d\n", getppid());
	}

and see if its output changes when you start to trace it.

> Still, the actual problem being debugged is something else.

Agreed, but we need to understand what the tools being used to
investigate the problem are doing ...

			regards, tom lane