On 01/17/2012 11:13 AM, Joel Jacobson wrote:
Since you only care about the parentfuncid in one level, it looks like
you will only be able to get a total call graph of all possible
function calls, and not each unique call graph per transaction.
True, for my purposes (function dependencies and
On Mon, Jan 16, 2012 at 2:23 PM, Martin Pihlak martin.pih...@gmail.com wrote:
My approach was to add parent oid to the per-backend function stats
structure - PgStat_BackendFunctionEntry. Also, I changed the hash key
for that structure to (oid, parent) pair. This means that within the
backend
On 01/09/2012 10:00 PM, Joel Jacobson wrote:
Because of this I decided to sample data in run-time to get a real-life
picture of the system.
Any functions not being called in productions are not that important to
include in the documentation anyway.
FWIW I have a similar problem - with a
Is this only to print out the stack upon errors? Looks like the stack is in
the variable error_context_stack. Is it always available containing all the
parent functions, even when there is no error? Can I reach it from within
pgstat.c?
2012/1/10 Jim Nasby j...@nasby.net
On Jan 9, 2012, at 2:08
Joel Jacobson j...@gluefinance.com wrote:
The perl script pg_callgraph.pl replaces the oids with actual
function names before generating the call graphs using GraphVIz:
Regardless of anything else, I think you need to allow for function
overloading. You could cover that, I think, by
On Jan 9, 2012, at 2:08 PM, Joel Jacobson wrote:
Generates call graphs of function calls within a transaction in run-time.
Related to this... we had Command Prompt write a function for us that would
spit out the complete call-graph of the current call stack whenever it was
called. Alvaro
