Proposed GUC Variable

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Proposed GUC Variable
Date: 2002-08-23 02:04:50
Message-ID: GNELIHDDFBOCMGBFGEFOEENICDAA.chriskl@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-08-23 02:22:24 Re: Release of v7.2.2 (Was: Re: @(#)Mordred Labs ad...)
Previous Message Lamar Owen 2002-08-23 01:57:59 Re: My head is spinning

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2002-08-23 02:33:00 more buffer paranoia
Previous Message J. R. Nield 2002-08-22 19:10:05 Fix for segfault in pgmodule.c: pgquery_dictresult()