Thread

1. trace_recovery_messages

   Fujii Masao <masao.fujii@gmail.com> — 2010-08-10T14:28:04Z

   Hi,
   
   The explanation of trace_recovery_messages in the document
   is inconsistent with the definition of it in guc.c.
   
   In the document,
   
   * trace_recovery_messages is categorized into DEVELOPER_OPTIONS
   * The default is WARNING
   * Parameter should be set in the postgresql.conf only
   
   But, in guc.c
   
   * trace_recovery_messages is categorized into LOGGING_WHEN
   * The default is DEBUG1
   * The context is PGC_SUSET
   
   ISTM the right is
   
   * Categorized into DEVELOPER_OPTIONS
   * The default is DEBUG1
   * The context is PGC_SIGHUP
   
   We should apply the attached patch which changes the document
   and guc.c as above?
   
   Regards,
   
   -- 
   Fujii Masao
   NIPPON TELEGRAPH AND TELEPHONE CORPORATION
   NTT Open Source Software Center
   

2. Re: trace_recovery_messages

   Simon Riggs <simon@2ndquadrant.com> — 2010-08-11T08:26:55Z

   On Tue, 2010-08-10 at 23:28 +0900, Fujii Masao wrote:
   
   > ISTM the right is
   > 
   > * Categorized into DEVELOPER_OPTIONS
   > * The default is DEBUG1
   > * The context is PGC_SIGHUP
   
   Don't think we should go live with default of DEBUG1.
   
   -- 
    Simon Riggs           www.2ndQuadrant.com
    PostgreSQL Development, 24x7 Support, Training and Services
   
   
   

3. Re: trace_recovery_messages

   Fujii Masao <masao.fujii@gmail.com> — 2010-08-11T08:40:12Z

   On Wed, Aug 11, 2010 at 5:26 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
   > On Tue, 2010-08-10 at 23:28 +0900, Fujii Masao wrote:
   >
   >> ISTM the right is
   >>
   >> * Categorized into DEVELOPER_OPTIONS
   >> * The default is DEBUG1
   >> * The context is PGC_SIGHUP
   >
   > Don't think we should go live with default of DEBUG1.
   
   You think the default should be WARNING as described,
   and guc.c should be changed accordingly? I have no
   objection to it.
   
   Regards,
   
   -- 
   Fujii Masao
   NIPPON TELEGRAPH AND TELEPHONE CORPORATION
   NTT Open Source Software Center
   
   

4. Re: trace_recovery_messages

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-08-18T19:23:02Z

   Fujii Masao <masao.fujii@gmail.com> writes:
   > The explanation of trace_recovery_messages in the document
   > is inconsistent with the definition of it in guc.c.
   
   Setting the default to WARNING is confusing and useless, because
   there are no trace_recovery calls with that debug level.  IMO the
   default setting should be LOG, which makes trace_recovery() a clear
   no-op (rather than not clearly a no-op).  There is circumstantial
   evidence in the code that this was the original intention:
   
   int			trace_recovery_messages = LOG;
   
   The documentation of the parameter is about as clear as mud, too.
   We need to explain what it does rather than just copy-and-paste
   a lot of text from log_min_messages.
   
   			regards, tom lane
   
   

5. Re: trace_recovery_messages

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-08-19T23:06:14Z

   Fujii Masao <masao.fujii@gmail.com> writes:
   > The explanation of trace_recovery_messages in the document
   > is inconsistent with the definition of it in guc.c.
   
   I've applied a patch for this.
   
   I was tempted to propose that we just rip out trace_recovery_messages
   altogether, but I suppose Simon would object.
   
   			regards, tom lane
   
   

6. Re: trace_recovery_messages

   Simon Riggs <simon@2ndquadrant.com> — 2010-08-25T09:36:00Z

   On Thu, 2010-08-19 at 19:06 -0400, Tom Lane wrote:
   > Fujii Masao <masao.fujii@gmail.com> writes:
   > > The explanation of trace_recovery_messages in the document
   > > is inconsistent with the definition of it in guc.c.
   > 
   > I've applied a patch for this.
   > 
   > I was tempted to propose that we just rip out trace_recovery_messages
   > altogether, but I suppose Simon would object.
   
   Thanks for keeping it in, hopefully it will help diagnose any errors.
   
   I laughed when I saw the commit message, so thanks for that.
   
   This is definitely a stop-gap facility. If you were to propose a more
   general facility for increasing log level of specific modules, I'm sure
   the rest of us would see that implemented across the rest of the code.
   
   -- 
    Simon Riggs           www.2ndQuadrant.com
    PostgreSQL Development, 24x7 Support, Training and Services
   
   
   

7. Re: trace_recovery_messages

   Robert Haas <robertmhaas@gmail.com> — 2010-08-25T11:26:42Z

   On Wed, Aug 25, 2010 at 5:36 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
   > This is definitely a stop-gap facility. If you were to propose a more
   > general facility for increasing log level of specific modules, I'm sure
   > the rest of us would see that implemented across the rest of the code.
   
   Yeah, I was thinking about that, too.
   
   -- 
   Robert Haas
   EnterpriseDB: http://www.enterprisedb.com
   The Enterprise Postgres Company