From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: enhanced stack trace for PL - print param args |
Date: | 2017-01-23 17:39:32 |
Message-ID: | CADkLM=dqu_ZYOzepAkoRm0AP=VY6w3i=P+TbzoNFDF-f=FZrYQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 15, 2017 at 1:27 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2017-01-23 17:45:03 | Re: Review: GIN non-intrusive vacuum of posting tree |
Previous Message | Corey Huinker | 2017-01-23 17:34:08 | Undefined psql variables |