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
|
Список | 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 по дате отправления: