Where are we on this? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
>> 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
