Re: Proposed GUC Variable - Mailing list pgsql-hackers

On Tue, 2002-08-27 at 16:54, Bruce Momjian wrote:
> 
> 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.

I could go for the first 1000 characters, but 80 is almost useless for
most of our stuff.  80 wouldn't get through the select list a good chunk
of the time.

If an application in the product environment is throwing an error, we'd
want the full thing.  Most of our internal systems are completely hands
off unless it's been scripted and tested elsewhere, so it's not like
user queries would be getting into it.

Perhaps a GUC for the length?  But I'd still opt for storing the whole
thing.  Yes, someone could fill up the disk but a rotating log would
help that.

> ---------------------------------------------------------------------------
> 
> 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, Pennsylvania 19073
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>