From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Edson Richter <edsonrichter(at)hotmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Proposal "stack trace" like debugging option in PostgreSQL |
Date: | 2016-07-31 20:31:12 |
Message-ID: | 9a8be88c-e543-1262-fbb2-3e82cd06afbc@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 07/31/2016 01:27 PM, Edson Richter wrote:
Please reply to list also
Ccing list.
>
>
>> 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
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Edson Richter | 2016-07-31 20:32:02 | Re: Proposal "stack trace" like debugging option in PostgreSQL |
Previous Message | Edson Richter | 2016-07-31 20:28:59 | Re: Proposal "stack trace" like debugging option in PostgreSQL |