On Fri, 25 Apr 2003, Tom Lane wrote:
> Hmm. Evidently the pgstat subprocess is dying immediately on launch.
> Checking the archives, I see that back then pgstat was in the habit of
> reporting its woes on stderr no matter what the elog destination was
> supposed to be :-(. So the actually useful message went to postmaster
> stderr, which more than likely is routed to /dev/null by your postmaster
> startup script.
>
> If you want to try to figure out what went wrong, you could alter the
> start script to enable collection of stderr output and then try to
> reproduce the problem.
It is possible that the disk was beyond minfree at that point, which would
explain why pgstat died. I'll have to test that scenario on a UML box to
avoid squishing my production server.
The problem though is still that whatever code is spawning pgstat is doing
so forever. Are you suggesting that because the error output isn't going
to the right place that postmaster is not detecting that it died? I'd
think that postmaster would instead check the return value (else how does
it determine atm that it failed?) and not loop once it's failed.
Erik Walthinsen <omega@temple-baptist.com> - System Administrator
__
/ \ GStreamer - The only way to stream!
| | M E G A ***** http://gstreamer.net/ *****
_\ /_