Tom Lane wrote:
> It's amazing to me that we've never
> gone back and improved on the original quick-and-dirty
> MemoryContextStats mechanism. I certainly find myself using that a
> lot for issues like tracking down memory leaks.
That code hasn't really gone anywhere since Neil tweaked the indentation
two years ago. What sorts of improvements were you looking for?
I started on trying to improve this area at one point but didn't get
far. My first step was going to be just wrapping the call into a UDF to
make it easier to reach without having to set loose gdb. I thought that
might expand the possible uses for MemoryContextStats to "help find a
memory leak safely on the production box", and therefore attact more
attention to improving it. People really don't like running gdb on
production, but a UDF dumping the same data wouldn't seem so risky. As
Daniel Farina pointed out to me one day in a "duh" moment, that idea is
quite obviously doomed by the fact that people want dumps from processes
that you won't be talking to in a UDF context. You won't be able to
find a leak in the background writer by dumping the context the UDF can
see. There would need to be some sort of IPC/signaling mechanism in
each process if you wanted it to work everywhere, and once that
realization hit I realized this was a deeper problem than it appeared.
If you want to make it easier to export into user space, it seems to me
the memory context stats data either needs to get pushed somewhere it's
easier to get to (the way the regular stats are), or there needs to be
some way of polling any random PG process to find it--presumably by
passing the request the pid you want to instrument. Neither of which
may really be a reasonable idea at all, particularly since that in most
cases, you're using a debugger to track your leak down only after
reproducing a test case for it.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com
