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
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
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.
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,
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
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
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
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
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
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
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
11 matches
Mail list logo