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

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?

In response to

Browse pgsql-hackers by date

  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