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 [EMAIL PROTECTED]) > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
