Re: Proposed GUC Variable

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(at)postgresql(dot)org)
>

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