[Pgpool-hackers] Found bug with debug_level

[jgdr at dalibo.com]

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.

> 
>> 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. 

Having pgPool beeing able to take care of its own log file is a high
priority 
though  :)

> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp