Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).
Date: 2010-01-07 04:14:42
Message-ID: 6584.1262837682@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 6, 2010 at 10:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> What tools do we have for identifying memory leaks?
>>
>> User complaints :-(

> YGTBFKM.

Not really. Given the memory context architecture, leaks are simply not
a big deal in 99% of the system. We just need a few coding rules like
"don't run random code in CacheMemoryContext" ;-)

> It seems like we should have a tool that dumps out every memory
> context in the system, with the number of allocations and frees and
> number of bytes allocated and freed since the last reset. Maybe the
> time of the last reset. You could run that before and after doing
> whatever it is that might leak and compare.

Once you've identified a place that "might leak" and a test case that
would exercise it, you've already done most of the work. What you're
describing sounds to me like a lot of work for not much return.

Furthermore, if you do have a leaking test case and you don't know
exactly where the leak is coming from, numbers about how big the leak is
aren't any help in finding the cause. What you really want is numbers
that are per palloc call site, which would not be simple to get. I have
occasionally wondered about hooking up something similar to valgrind for
this; but the problem is that it would drown you in false positives
because of the number of places where we intentionally leave stuff to be
cleaned up at context reset.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2010-01-07 04:53:35 pgsql: Remove all the special-case code for INT64_IS_BUSTED, per
Previous Message Bruce Momjian 2010-01-07 04:10:39 pgsql: More tablespace.c comment improvements.

Browse pgsql-hackers by date

  From Date Subject
Next Message Guy Rouillier 2010-01-07 04:52:19 Re: FM format modifier does not remove leading zero from year
Previous Message Hiroshi Inoue 2010-01-07 03:58:10 Re: libpq naming on Win64