>>> Fortunately we have syslog support now :-) but if we want to fix the >>> stderr logging problem we have to allow pgpool to save it into a given >>> file like with a -l logfile command line option or/and in the >>> configuration file with a 'log_to_file' option instead of letting the >>> user creating a shell redirection that is only useful at main process >>> startup. >> >> Problem with this aproach is we need a rog rotation functionality at >> the same time. Otherwise the logfile will become infinitely large >> until pgpool process restarts. IMO if we implement "log_to_file", we >> need our own log rotator as well. Probably these functions will be >> pretty much similar to PostgreSQL's one(aka. logging collector >> process) if we want to implement. > > IMHO, we shouldn't focus on rotation yet but just fix this issue. If > pgPool > need to rotate is own log file, it would be better to make it a seperate > patch.
I'm not against the log rotation patch be separate one. But I think log to file patch should include the ability to close and re-open the log file when certain signal is received. > Mind you, I even think rotation shouldn't be in the scope or PostgreSQL at > > all. We have some better ways to deal with rotation, logrotate itself is > much > better and functionnal than PostgreSQL. Can you elaborate why PostgreSQL's logger process is not good? I think your point was already examined when the discussions on logger process were going on the PostgreSQL hacker's list. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
