Re: Proposed GUC Variable

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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073