Re: [HACKERS] trace_recovery_messages
On Thu, 2010-08-19 at 19:06 -0400, Tom Lane wrote: Fujii Masao masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
On Wed, Aug 25, 2010 at 5:36 AM, Simon Riggs si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
Fujii Masao masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
Fujii Masao masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
On Wed, Aug 11, 2010 at 5:26 PM, Simon Riggs si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
On Fri, 2010-06-18 at 10:20 +0900, Fujii Masao wrote: On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane t...@sss.pgh.pa.us wrote: Fujii Masao masao.fu...@gmail.com 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 many messages that would actually get emitted at the default setting of the parameter. Yes. I was just concerned that frequent calls themselves may increase the overhead. Please share your oprofile output so we can see the problem. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
Fujii Masao masao.fu...@gmail.com 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 many messages that would actually get emitted at the default setting of the parameter. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trace_recovery_messages
On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane t...@sss.pgh.pa.us wrote: Fujii Masao masao.fu...@gmail.com 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 many messages that would actually get emitted at the default setting of the parameter. Yes. I was just concerned that frequent calls themselves may increase the overhead. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
