Re: [HACKERS] trace_recovery_messages

2010-08-25 Thread Robert Haas
On Wed, Aug 25, 2010 at 5:36 AM, Simon Riggs 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

Re: [HACKERS] trace_recovery_messages

2010-08-25 Thread Simon Riggs
On Thu, 2010-08-19 at 19:06 -0400, Tom Lane wrote: > Fujii Masao 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_mess

Re: [HACKERS] trace_recovery_messages

2010-08-19 Thread Tom Lane
Fujii Masao 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.

Re: [HACKERS] trace_recovery_messages

2010-08-18 Thread Tom Lane
Fujii Masao 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,

Re: [HACKERS] trace_recovery_messages

2010-08-11 Thread Fujii Masao
On Wed, Aug 11, 2010 at 5:26 PM, Simon Riggs 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 thi

Re: [HACKERS] trace_recovery_messages

2010-08-11 Thread Simon Riggs
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

[HACKERS] trace_recovery_messages

2010-08-10 Thread Fujii Masao
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 * tra

Re: [HACKERS] trace_recovery_messages

2010-06-18 Thread Simon Riggs
On Fri, 2010-06-18 at 10:20 +0900, Fujii Masao wrote: > On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane wrote: > > Fujii Masao writes: > >> We should make trace_recovery_messages available only when > >> the WAL_DEBUG macro was defined? > > > > No, because it's used in a lot of other contexts besides t

Re: [HACKERS] trace_recovery_messages

2010-06-17 Thread Fujii Masao
On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane wrote: > Fujii Masao writes: >> We should make trace_recovery_messages available only when >> the WAL_DEBUG macro was defined? > > No, because it's used in a lot of other contexts besides that. > >> Currently it's always >> available, so the standby seems

Re: [HACKERS] trace_recovery_messages

2010-06-17 Thread Tom Lane
Fujii Masao writes: > We should make trace_recovery_messages available only when > the WAL_DEBUG macro was defined? No, because it's used in a lot of other contexts besides that. > Currently it's always > available, so the standby seems to call elog() too frequently. Where? I don't see very ma

[HACKERS] trace_recovery_messages

2010-06-16 Thread Fujii Masao
Hi, We should make trace_recovery_messages available only when the WAL_DEBUG macro was defined? Currently it's always available, so the standby seems to call elog() too frequently. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via p