I have applied a modified version of this patch, attached. I trimmed
down the description of log_lock_waits to be more concise, and moved the
idea of using this to tune deadlock_timeout to the deadlock_timeout
section of the manual.
--
I will rework this before application to use LOG level.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It wouldn't really be any different from errcode(), but if you want
> >> I'll do it.
>
> > If you would just add the infrastructure I can add the LOG part.
>
> OK, I applied a patch that covers the same territory
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It wouldn't really be any different from errcode(), but if you want
>> I'll do it.
> If you would just add the infrastructure I can add the LOG part.
OK, I applied a patch that covers the same territory as your patch of
Wednesday even
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Perhaps the best thing would be to define an additional ereport
> >> auxiliary function, say errprintstmt(bool), that could set a flag
> >> in the current elog stack entry to control suppression of STATEMENT.
> >>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Perhaps the best thing would be to define an additional ereport
>> auxiliary function, say errprintstmt(bool), that could set a flag
>> in the current elog stack entry to control suppression of STATEMENT.
>> This would mean you couldn't
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I can create a global variable to control this, but the new elog level
> > seemed cleaner.
>
> What I don't like about the proposed patch is that it's nonorthogonal.
> I see no reason to suppose that LOG is the only possible elevel fo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can create a global variable to control this, but the new elog level
> seemed cleaner.
What I don't like about the proposed patch is that it's nonorthogonal.
I see no reason to suppose that LOG is the only possible elevel for
which it might be interest
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are people going to be happy that log_statement and
> > log_min_duration_statement output the statement twice?
>
> If those are the only cases you're worried about, a far simpler solution
> is to clear debug_query_string before instea
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are people going to be happy that log_statement and
> log_min_duration_statement output the statement twice?
If those are the only cases you're worried about, a far simpler solution
is to clear debug_query_string before instead of after emitting those
lo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What are *you* thinking? Yes, that patch has that line, but
> > log_statement and log_min_duration_statement is going to trigger
> > log_min_error_statement so you are going to get the statement printed
> > twice.
>
> What's wrong wi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What are *you* thinking? Yes, that patch has that line, but
> log_statement and log_min_duration_statement is going to trigger
> log_min_error_statement so you are going to get the statement printed
> twice.
What's wrong with that? If a statement trigg
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have coded up the following patch which places LOG just above ERROR in
> > log_min_error_statement.
>
> LOG_NO_STATEMENT? What *are* you thinking? The kindest word I can find
> for this is "baroque".
>
> What I had in mind was a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have coded up the following patch which places LOG just above ERROR in
> log_min_error_statement.
LOG_NO_STATEMENT? What *are* you thinking? The kindest word I can find
for this is "baroque".
What I had in mind was a one-line patch:
if (eda
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This is not the first GUC that has needed this.
>
> Exactly. I think that we simply made a mistake in the initial
> implementation of log_min_error_statement: we failed to think about
> whether it should use client or server priority
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This is not the first GUC that has needed this.
Exactly. I think that we simply made a mistake in the initial
implementation of log_min_error_statement: we failed to think about
whether it should use client or server priority ordering, and the
easy-to-c
Simon Riggs wrote:
> On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
>
> > I am a little concerned about a log_* setting that is INFO. I understand
> > why you used INFO (for log_min_error_messages), but INFO is inconsistent
> > with the log* prefix, and by default INFO doesn't appear in t
On Mon, 2007-02-26 at 14:52 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> The idea of the patch is that it generates a log message which then
> >>> invokes log_min_error_
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> The idea of the patch is that it generates a log message which then
>>> invokes log_min_error_statement so that the SQL statement is displayed.
>>> LOG is
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > The idea of the patch is that it generates a log message which then
> > invokes log_min_error_statement so that the SQL statement is displayed.
> > LOG is not on the list of options there, otherwise I
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> The idea of the patch is that it generates a log message which then
> invokes log_min_error_statement so that the SQL statement is displayed.
> LOG is not on the list of options there, otherwise I would use it.
As I said, you don't understand how the log
On Mon, 2007-02-26 at 14:11 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Yeh, LOG would be most appropriate, but thats not possible.
>
> You have not given any good reason for that.
The idea of the patch is that it generates a log message which then
invokes log_min_error
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Yeh, LOG would be most appropriate, but thats not possible.
You have not given any good reason for that.
> log_min_messages allows only DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1,
> INFO, NOTICE and WARNING for non-error states.
I don't think you understan
On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
> I am a little concerned about a log_* setting that is INFO. I understand
> why you used INFO (for log_min_error_messages), but INFO is inconsistent
> with the log* prefix, and by default INFO doesn't appear in the log
> file.
Yeh, LOG woul
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
file.
So, by default, the INFO is going to go to the user terminal, and not to
the
On Mon, 2007-02-19 at 19:38 +, Simon Riggs wrote:
> On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
> > > > Chris Campbell <[EMAIL PROTECTED]> writes:
> > > > > Is there additional logging information I can
26 matches
Mail list logo
