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

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Proposal "stack trace" like debugging option in PostgreSQL
Дата
Msg-id 9a8be88c-e543-1262-fbb2-3e82cd06afbc@aklaver.com
обсуждение исходный текст
Ответ на Proposal "stack trace" like debugging option in PostgreSQL  (Edson Richter <edsonrichter@hotmail.com>)
Список 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@hotmail.com; pgsql-general@postgresql.org
>> From: adrian.klaver@aklaver.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.klaver@aklaver.com


--
Adrian Klaver
adrian.klaver@aklaver.com


В списке pgsql-general по дате отправления:

Предыдущее
От: Edson Richter
Дата:
Сообщение: Re: Proposal "stack trace" like debugging option in PostgreSQL
Следующее
От: Edson Richter
Дата:
Сообщение: Re: Proposal "stack trace" like debugging option in PostgreSQL