Re: Logging parameters values on bind error

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Logging parameters values on bind error
Дата
Msg-id 3493.1349714959@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Logging parameters values on bind error  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: sortsupport for text
Следующее
От: Tom Lane
Дата:
Сообщение: Re: why can't plpgsql return a row-expression?