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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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