Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
В списке pgsql-hackers по дате отправления:
| От | Stephen Frost |
|---|---|
| Тема | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |
| Дата | |
| Msg-id | 20141002122309.GK28859@tamriel.snowman.net обсуждение |
| Ответ на | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) (Craig Ringer <craig@2ndquadrant.com>) |
| Список | pgsql-hackers |
* Craig Ringer (craig@2ndquadrant.com) wrote: > > The patch https://commitfest.postgresql.org/action/patch_view?id=885 > > (discussion starts here I hope - > > http://www.postgresql.org/message-id/4FE8CA2C.3030809@uptime.jp) > > demonstrates performance problems; LWLOCK_STAT, LOCK_DEBUG and > > DTrace-like approach are slow, unsafe for production use and a bit > > clumsy for using by DBA. > > It's not at all clear to me that a DTrace-like (or perf-based, rather) > approach is unsafe, slow, or unsuitable for production use. I've certainly had it take production systems down (perf, specifically), so I'd definitely consider it "unsafe". I wouldn't say it's unusable, but it's certainly not what we should have as the end-goal for PG. Thanks, Stephen
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера