Thread: trace_recovery_messages
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
Attachment
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.comPostgreSQL Development, 24x7 Support, Training and Services
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
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
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
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.comPostgreSQL Development, 24x7 Support, Training and Services
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