> 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.
Unfortunateky SIGUSR2 is used for different purpose in pgpool-II. (to wake up children waiting for 2nd stage of online recovery done). > 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. +1. > 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
