[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