[Pgpool-hackers] Found bug with debug_level

Tatsuo Ishii ishii at sraoss.co.jp
Fri Dec 31 04:47:39 UTC 2010


> Le 30/12/2010 16:01, jgdr at dalibo.com a écrit :
>> 
>> On Thu, 30 Dec 2010 23:19:07 +0900 (JST), Tatsuo Ishii
>> <ishii at sraoss.co.jp>
>> 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


More information about the Pgpool-hackers mailing list