Re: SQLERRD and dump of variables
| От | Joel Jacobson |
|---|---|
| Тема | Re: SQLERRD and dump of variables |
| Дата | |
| Msg-id | BANLkTin_REXZ4YZQ2vo9cxsan0wc1KOXzQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SQLERRD and dump of variables (Noah Misch <noah@leadboat.com>) |
| Список | pgsql-hackers |
2011/4/28 Noah Misch <noah@leadboat.com>
Thank you, very useful! This solved my problem. I wrote a comment at http://www.postgresql.org/docs/9.0/interactive/plpgsql-errors-and-messages.html.
Yes, the format of the string written to the log must support multi-level data strucutres, perhaps JSON would be a good choice.
Yes, for very large values, it's okay if they are truncated or perhaps truncated+a simple MD5-hash of the value, so you can check if it is equal to the excepted value. You are usually not interested in these anyway, since what you are looking for are probably things like ID-numbers, usernames, etc.
In the mean time, have you considered doing something like this instead?
EXCEPTION WHEN deadlock_detected
RAISE NOTICE '% var_foo % var_bar', var_foo, var_bar;
RAISE;
The information isn't as nicely aggregated, but you don't lose any details.
Thank you, very useful! This solved my problem. I wrote a comment at http://www.postgresql.org/docs/9.0/interactive/plpgsql-errors-and-messages.html.
Also keep in mind that you may have several PL/pgSQL functions in your callstack, and you'll want to capture the local variables at each level.
Yes, the format of the string written to the log must support multi-level data strucutres, perhaps JSON would be a good choice.
Consider the potential need to avoid logging very-large variable values. The
GUC could perhaps be a size limit (0 disables the feature entirely), not a
boolean.
Yes, for very large values, it's okay if they are truncated or perhaps truncated+a simple MD5-hash of the value, so you can check if it is equal to the excepted value. You are usually not interested in these anyway, since what you are looking for are probably things like ID-numbers, usernames, etc.
В списке pgsql-hackers по дате отправления: