Re: [RFC] obtaining the function call stack

Поиск
Список
Период
Сортировка
От decibel
Тема Re: [RFC] obtaining the function call stack
Дата
Msg-id 785BA0E4-4C91-49DC-9E10-6EACEDCC638C@decibel.org
обсуждение исходный текст
Ответ на Re: [RFC] obtaining the function call stack  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [RFC] obtaining the function call stack  ("A.M." <agentm@themactionfaction.com>)
Список pgsql-hackers
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane wrote:
>>> The performance and error recovery implications are unfavorable.
>>> Just how badly do you need this, and for what?
>
>> Mainly for debugging.  The situation is such that there is a lot of
>> functions and very high load.  The functions have embedded "debug  
>> elogs"
>> and the intention is to call them only if the function was called  
>> in a
>> particular context.
>
> I can't really see that as sufficiently widely useful to justify
> inserting such a mechanism.
>
> I suspect also that you are defining the problem the wrong way ---  
> this
> user doesn't want a generic fmgr call stack, he wants a plpgsql stack.
> Which is something the plpgsql debugger could be taught to do, if it
> doesn't already, thus avoiding the overhead the 99.9% of the time that
> you don't need it.

Actually, this could conceivably be called from other languages, such  
as plPerl.

But it sounds like this can be done via an add-on, so no need to add  
it directly to the backend.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828




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

Предыдущее
От: decibel
Дата:
Сообщение: Re: Predicate migration on complex self joins
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: Predicate migration on complex self joins