[Pgpool-hackers] Found bug with debug_level

[Gilles Darold]

Hi Tatsuo,

This part has been delayed for a later date. I'm currently working on
other major enhancements for PgPool. If nobody can handle this patch, I
will do the work in one or 2 weeks.

The other contributions I'm working on and that seems more important for
me :

    - Add a pcp command to promote a given master (not only the
following up node, but any backend in the pgpool line)
   - Add a second level to failover witch allow executing some scripts
after failover is done.

I will add some discussion on the mailing about that points as soon as I
have some time.

Regards,

-- 
Gilles Darold
http://dalibo.com - http://dalibo.org


Le 11/01/2011 02:56, Tatsuo Ishii a écrit :
> 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, 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