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)
Список
Дерево обсуждения
[RFC] obtaining the function call stack Alvaro Herrera <alvherre@commandprompt.com>
Re: [RFC] obtaining the function call stack Pavel Stehule <pavel.stehule@gmail.com>
Re: [RFC] obtaining the function call stack Alvaro Herrera <alvherre@commandprompt.com>
Re: [RFC] obtaining the function call stack Pavel Stehule <pavel.stehule@gmail.com>
Re: [RFC] obtaining the function call stack Alvaro Herrera <alvherre@commandprompt.com>
Re: [RFC] obtaining the function call stack Tom Lane <tgl@sss.pgh.pa.us>
Re: [RFC] obtaining the function call stack Alvaro Herrera <alvherre@commandprompt.com>
Re: [RFC] obtaining the function call stack Tom Lane <tgl@sss.pgh.pa.us>
Re: [RFC] obtaining the function call stack decibel <decibel@decibel.org>
Re: [RFC] obtaining the function call stack "A.M." <agentm@themactionfaction.com>
Re: [RFC] obtaining the function call stack Jaime Casanova <jcasanov@systemguards.com.ec>
Re: [RFC] obtaining the function call stack decibel <decibel@decibel.org>
Re: [RFC] obtaining the function call stack Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote: > Alvaro Herrera 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 по дате отправления