> > 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).
Advertising
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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
