On 11/11/2012 12:50 AM, Carlos Henrique Reimer wrote: > Hi, > > How is the best way to attach a debugger to the SELECT and identify > why is it exhausting server storage.
This page is more focused on getting a stack trace after a crash, but provides some information about how to identify the backend to connect to, how to connect with gdb, etc: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD Short version is: Get the pid of the backend that's growing with SELECT pg_backend_pid() before running the test, from `top`, or from pg_stat_activity. gdb -p pid_of_backend when you get a (gdb) prompt: cont<enter> Let the memory use grow until you think it's fairly big. Hit control-C in the gdb terminal to interrupt execution of the backend. You'll get another (gdb) prompt. Now follow Tom's advice: > In gdb, > call MemoryContextStats(TopMemoryContext) > should produce some useful information on the process's stderr file. It may also be helpful to have a stack trace or two or three to see what Pg is doing while it's running and growing, so if you want, also run: bt then "cont" again, control C, bt again, cont, control c, bt, and provide the copied and pasted backtraces in case they provide additional information about what's going on. -- Craig Ringer
