Re: [PATCH] dtrace probes for memory manager

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: [PATCH] dtrace probes for memory manager
Дата
Msg-id 1260562071.2642.68.camel@localhost
обсуждение исходный текст
Ответ на Re: [PATCH] dtrace probes for memory manager  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] dtrace probes for memory manager  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane píše v pá 11. 12. 2009 v 14:38 -0500:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I thought we had an idea of using the AllocSet dispatch mechanism to
> > make this zero-overhead in the case where the probes are not enabled.
> > What happened to that notion?
> 
> I must have missed that discussion, but +1 --- should be possible to get
> to zero-overhead-when-off that way.  The trick is to figure out
> what/where enables the alternate implementation.  The current design
> assumes that the callers of FooContextCreate choose the implementation,
> but we don't want that here.

I thought about it. I think we can use GUC variable (e.g. dtraced_alloc)
and hook switch pointers to dtraced AsetFunctions. The problem is how to
distribute to all backend.
Zdenek




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Adding support for SE-Linux security
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Adding support for SE-Linux security