Re: stats collector dies in current - Mailing list pgsql-hackers

From Oliver Jowett
Subject Re: stats collector dies in current
Date
Msg-id 411EEF8C.2030307@opencloud.com
Whole thread Raw
In response to Re: stats collector dies in current  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: stats collector dies in current  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: stats collector dies in current  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> 
>>In that context, is SIGTSTP similar to SIGSTOP in that it cannot be 
>>caught or ignored?
> 
> 
> Possibly.  I've reproduced the problem here on an RHL 8 system
> (2.4.18 kernel) and I think it's a kernel bug.  Points:

[...]

I can reproduce this on a 2.6.7 kernel.

I think pqsignal should be passing SA_NOCLDSTOP in sa_flags, or 
alternatively that the stats buffer process should check that its child 
really did die rather than receive a stop signal. The sigaction manpage 
says:

>        sa_flags specifies a set of flags which modify the behaviour of the signal handling process. It is formed by
thebit-
 
>        wise OR of zero or more of the following:
> 
>               SA_NOCLDSTOP
>                      If signum is SIGCHLD, do not receive notification when child processes stop (i.e., when child
processes
>                      receive one of SIGSTOP, SIGTSTP, SIGTTIN or SIGTTOU).

signal(7) says that SIGCHLD is generated when a child is stopped or 
terminated.

A bit of experimentation in the stats buffer process seems to confirm 
this -- while it is receiving a SIGCHLD, calling waitpid() with WNOHANG 
returns immediately with no dead processes.

-O


pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: 8.0 beta status
Next
From: Tom Lane
Date:
Subject: Re: stats collector dies in current