Re: Proposed GUC Variable - Mailing list pgsql-hackers

I had an idea on this.  It seems pretty pointless to show a query error
without a query, but some queries are very large.

How about if we print only the first 80 characters of the query, with
newlines, tabs, and spaces reduced to a single space, and send that as
LOG to the server logs.  That would give people enough context, and
prevent us from having another GUC variable.

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

Gavin Sherry wrote:
> Hi all,
> 
> Quick hack while eating a sandwich.
> 
> template1=# select * frum;
> ERROR:  parser: parse error at or near "frum" at character 10
> ERROR QUERY: select * frum;
> 
> Now, I did say quick hack. 'ERROR QUERY' isn't a new error level I just
> strcat() it to buf_msg in elog() if debug_print_error_query is
> true. Question: from Chris's request it doesn't sound like there is much
> use writing this to the client. Does everyone else feel the same way?
> 
> If so, I'll patch it up and send off.
> 
> Gavin
> 
> On Thu, 22 Aug 2002, Bruce Momjian wrote:
> 
> > 
> > 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
> > > 
> > 
> > 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

--  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