Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > However, looking at the issue of backends all reloading their
> > postgresql.conf files at different times and sending output to different
> > files, I wonder if it would be best to create a log process and have
> > each backend connect to that. That way, all the logging happens in one
> > process.
>
> That was something that bothered me too. I think in the patch as given,
> the GUC parameter determining the logfile name would have to be
> PGC_POSTMASTER, ie, you could not change it on the fly because the
> backends wouldn't all switch together. There may be some finer-grain
> timing issues as well.
>
> On the whole I think that capturing all the backends' stderr via a pipe
> and doing the file rotation in a single downstream process is a *much*
> cleaner solution. However, I've been saying that right along and
> haven't been listened to...
I saw Andreas demonstrating the viewing of server log files from pgadmin
at Germany Linuxtag, and it certainly was impressive. However, for
heavy, general usage, I don't think this patch is going to work.
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
was also interesting to do the log rotate as a database call.
The only idea I have is for the postmaster to close its stderror the
create a pipe to roatelogs and someone send all messages into there, and
pass the file name from postgresql.conf to that rotatelogs program.
Crazy, I know, but that is the best I can think of. We would then need
a use some API to read the log files, and find the valid numbered log
files. We could also control log file rotations via signals to the log
process.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073