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 по дате отправления: