Re: Logging parameters values on bind error - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Logging parameters values on bind error
Date
Msg-id 3493.1349714959@sss.pgh.pa.us
Whole thread Raw
In response to Logging parameters values on bind error  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
List pgsql-hackers
Jehan-Guillaume de Rorthais <jgdr@dalibo.com> writes:
> PFA a patch that catch any error while creating the query plan and add
> parameters values to the error message if log_statement or
> log_min_duration_statement would have logged it.

If that works, it's only by accident --- you're not supposed to add more
info to an error object after the error has been thrown.  What's worse,
if the original error had a DETAIL message, you're overwriting it.

The right way to do this type of thing, which is also cheaper than
PG_TRY on most platforms, is to set up an ErrorContextCallback stack
entry to call a function that adds extra information as a CONTEXT line.
There are lots of examples in the code base.

However ... I'm unconvinced that this can work safely at all.  Note the
check in errdetail_params that causes it to not do anything in an
aborted transaction.  Once you have caught an error, the current
transaction really has to be considered aborted, even if xact.c hasn't
been told about it yet.  So this patch is cheating with both hands, and
it will break given the right combination of error and parameter
datatypes.

A less dangerous approach would be to only attempt to print parameter
values that were supplied in text format.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: sortsupport for text
Next
From: Tom Lane
Date:
Subject: Re: why can't plpgsql return a row-expression?