Greg Smith <g...@2ndquadrant.com> writes:
> Tom Lane wrote:
>> It's amazing to me that we've never
>> gone back and improved on the original quick-and-dirty
>> MemoryContextStats mechanism.
> That code hasn't really gone anywhere since Neil tweaked the indentation
> two years ago. What sorts of improvements were you looking for?
Not anything like what you were thinking about, apparently ;-). What
I wish for the most often is a way to track palloc usage down to the
particular file/line of the alloc call. This is obviously not something
that we'd pay the overhead for in a standard build, but I would love to
be able to build a debug version that could do it when I needed. There
are malloc substitutes that can do this, but the palloc layer means that
they're not especially useful for debugging the PG backend.
Of course something like that doesn't have to have anything to do with
what Zdenek was wishing for, but it just struck me that creating a
stats-oriented shim layer in the memory context stuff is playing on
pretty much the same turf.
> 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.
Just for context: the reason MemoryContextStats is designed as it is
is so that it has a reasonable chance of telling you something useful
about an out-of-memory failure. When you're down to your last ten
bytes, it's not going to help if your reporting mechanism wants to
allocate a data structure to put its results in. So it writes to stderr
and nothing else. It may well be that that constraint means we can
never do anything really creative with MemoryContextStats per se.
But I see the use-case for other mechanisms as being to get some info
before we reach the point of having our backs to the wall.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
