> > 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,

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


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to