> > Probably the big thing this program was trying to solve was for the
> > server to know the output file name, even with log file
> rotation, and
> > I don't see a pipe and 'rotatelogs' process really addressing this.
>
> It could be done. Given the infrastructure we have now, it's
> possible to imagine the log capture process being a child of
> the postmaster that can respond to GUC SIGHUPs (or forget
> that and just freeze the file name pattern at PGC_POSTMASTER
> time, which isn't really that big a drawback).
> 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?
The other option would be to go with a syslog-style implementation,
which you write explicitly to over a socket. But that won't address your
concern below (from other mail).
> 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? Just getting to the normal backend
output would probably be a big win in most sitations, wouldn't it? In
the case these libraries put out information, we get an elog() call *as
well*, don't we? Then you could easily redirect stderr somewhere on the
server, while still processing "ordinary elog output" through the log
manager.
//Magnus