Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I have observed the following situation a few times now (weeks or months
> apart), most recently with 8.3.7. Some postgres child process crashes.
> The postmaster notices and sends SIGQUIT to all other children. Once
> all other children have exited, it would enter recovery. But for some
> reason, some children are not processing the SIGQUIT signal and are
> basically just stuck. That means the whole database system is then
> stuck and won't continue without manual intervention. If I go in
> manually and SIGKILL the offending processes, everything proceeds
> normally, recovery finishes, and the system is up again.
We need some investigation into why that is happening.
> I haven't had the chance yet to analyze why the SIGQUIT signals are
> getting stuck. Be that as it may, it appears there are no provisions
> for this case. I couldn't find any documentation or previous reports on
> this sort of thing. One might imagine a feature where the postmaster
> resorts to throwing SIGKILLs around after a while, similar to how init
> scripts are sometimes set up.
I'd prefer not to go there, at least not without a demonstration that
this will solve a bug that's unsolvable otherwise. If a child is
really stuck in a state that doesn't accept SIGQUIT, it probably
won't accept SIGKILL either (eg, uninterruptable disk wait). Or maybe
we just have some errant code that is blocking SIGQUIT; but that's
a garden variety bug IMO, not something that needs major new postmaster
logic to work around.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-09-23 14:20:22|
|Subject: Getting the red out (of the buildfarm)|
|Previous:||From: Petr Jelinek||Date: 2009-09-23 12:40:48|
|Subject: Re: [PATCH] DefaultACLs|
pgsql-admin by date
|Next:||From: Isabella Ghiurea||Date: 2009-09-23 15:47:10|
|Subject: Re: db size and tables size difference|
|Previous:||From: Rafael Domiciano||Date: 2009-09-23 13:07:47|
|Subject: Authentication Postgres user via LDAP|