Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-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

pgsql-hackers by date

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

pgsql-committers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group