From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposed GUC Variable |
Date: | 2002-08-23 02:46:31 |
Message-ID: | 200208230246.g7N2kVP24851@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Someone asked for that recently, and the email is in my mailbox for
consideration. I think it is a great idea, and we have
debug_query_string that holds the current query. You could grab that
from elog.c. Added to TODO:
* Add GUC parameter to print queries that generate errors
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
> Hi,
>
> My primary use of Postgres is as the backend database for a busy web site.
> We have a cron job that just emails us the tail of our database, php, apache
> logs every night. That way we can see some problems.
>
> These logs almost always contain some errors. For instance, this is what I
> see at the moment:
>
> 2002-08-22 19:21:57 ERROR: pg_atoi: error in "334 - 18k": can't parse " -
> 18k"
>
> Now there's plenty of places that accept numeric input in the site and
> obviously there's a bug in some script somewhere that's not filtering the
> input properly or something. However - the error message above is useless
> to me!!!
>
> So, what I'd like to propose is a new GUC variable called
> 'debug_print_query_on_error' or something. Instead of turning on
> debug_print_query and having my logs totally spammed up with sql, this GUC
> variable would only print the query if an actual ERROR occurred. This way I
> could nail the error very quickly by simply finding the query in my
> codebase.
>
> Is this possible? At the stage of processing where the elog(ERROR) occurs,
> do we still have access to the original query string?
>
> Comments?
>
> Chris
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-08-23 02:52:25 | Re: Release of v7.2.2 (Was: Re: @(#)Mordred Labs ad...) |
Previous Message | Bruce Momjian | 2002-08-23 02:40:50 | Re: My head is spinning |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-23 02:54:24 | Re: NAMEDATALEN doc update |
Previous Message | Neil Conway | 2002-08-23 02:44:31 | NAMEDATALEN doc update |