Re: Proposal "stack trace" like debugging option in PostgreSQL - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Proposal "stack trace" like debugging option in PostgreSQL
Date
Msg-id a2dd09e2-3cb6-0c09-6536-6e9b66f8cb40@aklaver.com
Whole thread Raw
In response to Proposal "stack trace" like debugging option in PostgreSQL  (Edson Richter <edsonrichter@hotmail.com>)
Responses Re: Proposal "stack trace" like debugging option in PostgreSQL
List pgsql-general
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?

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.

>
> 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.klaver@aklaver.com


pgsql-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: restore a specific schema from physical backup
Next
From: Jason Dusek
Date:
Subject: Re: Uber migrated from Postgres to MySQL