Skip site navigation (1) Skip section navigation (2)

Re: [RFC] obtaining the function call stack

From: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] obtaining the function call stack
Date: 2009-07-13 21:00:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Jul 13, 2009, at 4:51 PM, decibel wrote:

> On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)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.

How would I go about generating a meaningful backtrace for a plpgsql  
function that calls a plperl function? One would also expect a C  
function which calls a plpgsql function to appear, too, no? Shouldn't  
there be a unified backtrace subsystem?


In response to


pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2009-07-13 21:02:51
Subject: Re: [RFC] obtaining the function call stack
Previous:From: Jaime CasanovaDate: 2009-07-13 20:58:24
Subject: Re: Predicate migration on complex self joins

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group