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

Re: logging statement levels

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logging statement levels
Date: 2004-03-31 15:55:04
Message-ID: 200403311555.i2VFt4X00849@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> 
> >Andrew Dunstan wrote:
> >  
> >
> 
> 
> wow. that was nearly 3 months ago ...

Oh, I remember why I kept this email now. I am going to try to code
this.

> Subsequent discussion suggested we should add "syntax-errors" to the 
> allowed values (and I would favor making it the default).

We already have log_min_error_statement.  Seems that is what should be
used if someone wants only syntax errors.

> The problem is this - in order to make the decision about whether or not 
> to log, we need to have parsed the statement (unless the level is set 
> to  "all").  My simple approach, which would mean that the entire patch 
> would amount to around 100 lines, maybe, plus docco,  would have the (I 
> think) trivial side effect of reversing the order in which a logged 
> statement and the corresponding parse error log entry appeared. You 
> objected to that effect, so I stopped work on it.
> 
> Now I can think of a couple of different approaches which would not have 
> this effect:
> a. embed a time machine in postgres so we can make a decision based on 
> information we do not yet have, or
> b. find some spot where we can trap the parse error log message before 
> it is emitted and then first log the statement. That spot is probably 
> somewhere in src/backend/utils/error/elog.c, but I am not quite sure where.
> 
> I have rejected as ugly and unmaintainable monkeying with the parser 
> itself to produce the desired effect, and I regret that idea a is beyond 
> my humble abilities :-)

I will start on this now.  Thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-03-31 15:55:24
Subject: Re: with vs without oids in pg_catalog.*
Previous:From: scott.marloweDate: 2004-03-31 15:53:10
Subject: Re: pg_dump end comment

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-03-31 16:19:07
Subject: Re: Some Documentation Changes
Previous:From: scott.marloweDate: 2004-03-31 15:53:10
Subject: Re: pg_dump end comment

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