Re: Proposal "stack trace" like debugging option in PostgreSQL

From: Edson Richter <edsonrichter(at)hotmail(dot)com>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Proposal "stack trace" like debugging option in PostgreSQL
Date: 2016-07-31 20:28:59
Message-ID: COL131-W4945D01CCF031BDC843A2DCF030@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Subject: Re: [GENERAL] Proposal "stack trace" like debugging option in PostgreSQL
> To: edsonrichter(at)hotmail(dot)com; pgsql-general(at)postgresql(dot)org
> From: adrian(dot)klaver(at)aklaver(dot)com
> Date: Sat, 30 Jul 2016 15:26:42 -0700
>
> On 07/30/2016 10:52 AM, Edson Richter wrote:
> > Dear community,
> >
> >
> > Sorry if this is not the right place for proposing new features. Also,
> > sorry if I'm proposing something already existing.
> >
> > I do currently use the "debug" extension to better understand the
> > entrophy of my application regarding database.
>
> Can you be more specific about what you mean by debug extension?
>

pgAdmin III debugger:shared_preload_libraries = 'plugin_debugger' # (change requires restart)> > It might help provide folks with an idea of what you are looking for.> > >> > But in production this is not possible, and I would to propose a feature> > that has less impact over production then a debug extension: a> > stacktrace of calls.> >> > Simular to Java stack traces, but disabled by default. When enabled, In> > case of an event like "duplicate key" (or a function raise exception) or> > other similar problems that wont allow the database to execute the SQL> > command,the strack trace will bring the complete list of function call.> > Have you tried cranking up the log level:> > https://www.postgresql.org/docs/9.5/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN> > to one of the debug levels. Though that will result in a lot of log > output if you leave it on for any length of time.> Yes - I get the statements, but in case of an exception, I don't get the stack call showing how deep my function call is, which order has been in place. One update, insert or delete can throw a trigger that will cascade many levels until the problem is found.And, in general, is a bad idea (IMHO) to enable higher levels of logging in production systems when nothing is wrong. The stack trace is helpful when you don't have the logging, but something unexpected happens and you need more details. And, also, is unlikely you will be able to reproduce the sequence of error without that additional information.Edson Richter> >> > This would help to track down problems that escaped the development and> > test environments, and reached the production systems.> >> >> > If this feature already exists, please kindly point me to the docs. If> > not, please consider adding this in a future release.> >> >> > Thanks,> >> >> > > -- > Adrian Klaver> adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2016-07-31 20:31:12 Re: Proposal "stack trace" like debugging option in PostgreSQL
Previous Message Tom Lane 2016-07-31 15:56:11 Re: Proposal "stack trace" like debugging option in PostgreSQL