RE: libpq debug log
От | Iwata, Aya |
---|---|
Тема | RE: libpq debug log |
Дата | |
Msg-id | 71E660EB361DF14299875B198D4CE5423DE804A9@g01jpexmbkw25 обсуждение исходный текст |
Ответ на | Re: libpq debug log (Jacob Champion <pchampion@pivotal.io>) |
Ответы |
RE: libpq debug log
|
Список | pgsql-hackers |
Hi Jacob san, Thank you for your comment! And sorry for late reply... > Couple additional thoughts from a read-through of the patch: > > - PQtrace() and the new trace-logging machinery overlap in some places but > not others -- and if both are set, PQtrace() will take precedence. > It seems like the two should not be separate. I understand. This log is acquired for the purpose of investigating the cause part (server side or application side) whenperformance is bad. So I will search whether getting other place of PQtrace() is necessary or not. And I will reply after the research, please wait for a while a little. > - It isn't immediately clear to me how the new information in the logs is > intended to be used in concert with the old information. Maybe this goes back > to the comments by Tom and Robert higher in the thread -- that an overhaul > of the PQtrace system is due. This patch as presented would make things a > little worse before they got better, I think. > > That said, I think the overall idea -- application performance information > that can be enabled via the environment, without requiring debugging > privileges on a machine or the need to manually correlate traces made by other > applications -- is a good one, and something I would use. Thank you. I think so, too. Some applications cannot be stopped to add the PQtrace() code. Regards, Aya Iwata
В списке pgsql-hackers по дате отправления: