"Magnus Hagander" <mha@sollentuna.net> writes:
>> You'd need the postmaster to create the pipe and then
>> re-point its own stdout and stderr at it, but that's doable
>> on Unixen at least (I'm less sure about Windows).
> Given the issues we've had with stdout/stderr on mingw, I'm not
> convinced it will work there. But I'm not convinced it won't work either
> :-) What would be the portable way to do it on *nix - I could always run
> some tests on w32. Just "stderr = mynewpipe;" is a bit too simplistic,
> right?
Given that you have a pipe, I'd do something like
fclose(stderr);
stderr = fdopen(dup(p[0]), "a");
or possibly just
close(2);
d = dup(p[0]);
Assert(d == 2);
which would substitute the pipe into descriptor 2 without touching the
state of the user-level stderr file. This has the advantage that you
don't have to assume you can assign to the stderr macro. (If you do do
it the first way, you'd probably need an additional call to force the
buffering mode back to linebuffered or unbuffered.)
I don't have a problem with #ifdef'ing this part if something slightly
different is needed on Windows, though.
>> The fundamentally unfixable problem with his method is that
>> it can only capture elog output, not stderr output from
>> libraries that we don't control (the dynamic linker being the
>> biggest case, but there are others).
> How common are these issues really?
Exceedingly. I've lost count of the number of times we've needed to
look at the stderr output of someone's dynamic linker because we had
no other way to debug a problem with loading a shared library. I'm
really not going to accept a "logging" solution that can't handle it.
(And yes, this is one of the big complaints against our syslog
implementation.)
regards, tom lane