Skip site navigation (1) Skip section navigation (2)

Re: [martin@bugs.unl.edu.ar: BUG in logs]

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Martin Marques <martin(at)bugs(dot)unl(dot)edu(dot)ar>
Cc: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [martin@bugs.unl.edu.ar: BUG in logs]
Date: 2006-04-18 00:52:30
Message-ID: 200604180052.k3I0qU701263@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
I have looked at this behavior, which indeed is new for 8.1.  The change
was caused by code I think I did to improve the behavior of
log_statement, specifically streamlining how we check for the type of
command.

In looking at reverting to the 8.0 behavior of logging error commands
with 'all', I see it is going to be hard to do, specifically since we
added behavior of logging the PREPARE query when EXECUTE is sent.  I
don't think we want to lose that feature, and to have it we have to
first parse the statement, with possible exit on error.

What I have done is to document that errors are not output by
log_statement, and added as suggestion to use log_min_error_statement
for this purpose.  I also fixed the code so the first EXECUTE has it's
prepare, rather than the last which is what was in the current code.

I also removed the "protocol" prefix from the PREPARE output, because in
fact both protocol and SQL-level prepares can be executed by SQL
EXECUTE.

Patch attached.  I have backpatched this to 8.1.X.

---------------------------------------------------------------------------

Martin Marques wrote:
> 
> OK, you're right about the log_min_error_statement value, but this behaviour has changed from 8.0. In earlier versions ERROR statements did get logged if log_statment was set to all or in 7.4, set to "on" DMaybe I missed something in the changelog of 8.1?
> 
> On Tue, 11 Apr 2006 23:51:51 +0200, "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> wrote:
> >> From: Martin Marques <martin(at)bugs(dot)unl(dot)edu(dot)ar>
> >> I encountered a rare BUG in the way PG is logging. Let me first enlight
> > with some configuration I have and PG version:
> > 
> > Perhaps I'm missing something but I think it's not a bug but a
> > configuration problem.
> > 
> >>  log_min_error_statement    | panic
> > 
> > If you set this one to error instead of panic, you will have your
> > failed statements logged.
> > 
> >>  log_statement              | all
> > 
> > This one only logs successful queries so it's normal you don't have
> > the statement in the log file if it fails.
> > 
> > Regards,
> > 
> > 
> -- 
> ---------------------------------------------------------
> Lic. Mart?n Marqu?s         |   SELECT 'mmarques' || 
> Centro de Telem?tica        |       '@' || 'unl.edu.ar';
> Universidad Nacional        |   DBA, Programador, 
>     del Litoral             |   Administrador
> ---------------------------------------------------------
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2006-04-18 00:58:36
Subject: Re: [Win32] Problem with rename()
Previous:From: Peter BrantDate: 2006-04-17 23:53:56
Subject: [Win32] Problem with rename()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group