Re: Sampling profiler updated
От | Itagaki Takahiro |
---|---|
Тема | Re: Sampling profiler updated |
Дата | |
Msg-id | 20090722093930.A05A.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Sampling profiler updated (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
trace hooks (for 2nd commitfest)
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > For the record, I think this patch is a waste of manpower and we should > rely on dtrace/systemtap. However, if we are going to make our own > homegrown substitute for those facilities, a minimum requirement should > be that it uses the dtrace macros already put into the sources, rather > than expecting that it gets to clutter the code some more with its own > set of tracing markers. How about export dtrace functions as hook function pointers? For example: void (*LWLOCK_WAIT_START_hook)(int, int); #define TRACE_POSTGRESQL_LWLOCK_WAIT_START(INT1, INT2) \ if (LWLOCK_WAIT_START_hook== NULL); else \ LWLOCK_WAIT_START_hook(INT1, INT2) #define TRACE_POSTGRESQL_LWLOCK_WAIT_START_ENABLED()\ (LWLOCK_WAIT_START_hook != NULL) If there were such hooks, my profiler could be implemented as a loadable module on top of the hooks. It might be good to initialize LWLOCK_WAIT_START_hook with lwlock__wait__start(). If do so, dtrace probes still work and we can avoid if-null checks for each call. If acceptable, I'll also suggest new probe functions like SLEEP, SEND, RECV, SPINLOCK_FAILURE and so on. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: