Re: Logging parameters values on bind error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logging parameters values on bind error
Date: 2012-10-08 16:49:19
Message-ID: 3493.1349714959@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-10-08 16:53:10 Re: why can't plpgsql return a row-expression?
Previous Message Peter Geoghegan 2012-10-08 16:26:15 Re: sortsupport for text