Le 30/12/2010 16:01, [email protected] a écrit : > > On Thu, 30 Dec 2010 23:19:07 +0900 (JST), Tatsuo Ishii > <[email protected]> > wrote: >>>>> 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. > > sure, IIRC, the signal is SIGUSR2 with PostgreSQL. >
I think we need two patches at most. First one to push logs in a file (with a signal to rotate the file). Second one for rotation. But please, please, keep same name for same parameter. logging_collector. log_filename, log_directory. I don't think we need the rotation patch, but if Gilles wants to work on it, I won't complain :) >>> 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. > > It probably has been discussed on -hackers yes. Moreover, I didn't write > PostgreSQL's logger process is not good though. > > I think external projects dedicated to log rotation are much better and > functional: better frequency control, compression, retention. IMO, such > functionalities are not in the scope of PostgreSQL or pgPool. > > Don't get me wrong, I don't mind having such options in both projects, I > just > think they have really low priority. > +1 > Having pgPool beeing able to take care of its own log file is a high > priority though :) +1 -- Guillaume http://www.postgresql.fr http://dalibo.com _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
