Re: [HACKERS] proposal: enhanced stack trace for PL - print param args

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: [HACKERS] proposal: enhanced stack trace for PL - print param args
Дата
Msg-id CADkLM=dqu_ZYOzepAkoRm0AP=VY6w3i=P+TbzoNFDF-f=FZrYQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] proposal: enhanced stack trace for PL - print param args  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Sun, Jan 15, 2017 at 1:27 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi

Proposed result:
postgres=# select foo(0, 100);
ERROR:  division by zero
CONTEXT:  PL/pgSQL function foo(double precision) line 3 at RETURN
ARGUMENTS: a=0, b=100

+1 This would be useful in cases where an app calls one procedure and then disconnects. It's hard to know which of the thousands of invocations caused the error.
 

* only function parameters are printed - no local parameters

+1, we'd have no insight into variables inside the function anyway.
 
* the line of arguments will be limited - X chars ?

+1
 
* the content of variable should be limited - X chars ? - maybe 40 chars

This function can has impact on performance - so it should be explicitly enabled with some GUC - like extra_back_trace or some similar. Probably before any call the function parameters and related out functions should be copied to safe memory context. More it can increase press on Error Memory Context and possibly on log size.

func_args_back_trace? 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Corey Huinker
Дата:
Сообщение: [HACKERS] Undefined psql variables
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree