From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ). |
Date: | 2010-01-07 03:00:08 |
Message-ID: | 603c8f071001061900l77475439l1f444cffc09b64a3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Wed, Jan 6, 2010 at 6:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 3. Invoking tablespace_reloptions while switched into
> CacheMemoryContext. This isn't a crasher, but it strikes me as a bad
> idea because if reloptions.c happens to leak anything, that'll represent
> a permanent (session-lifespan) memory leak. And it's complicated enough
> that being sure it doesn't leak anything is hard.
What tools do we have for identifying memory leaks?
> I think you should
> invoke tablespace_reloptions in the caller's memory context, and then if
> it succeeds, copy the result into CacheMemoryContext. That would
> probably require fixing the problem you noted earlier today about
> making TableSpaceOpts be a valid bytea value, so that it'll be easy to
> copy (then you can use datumCopy, for instance).
I think I'll just copy Alvaro's existing pattern in relcache.c, which
just uses palloc0 and memcpy.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-01-07 03:13:44 | Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ). |
Previous Message | Robert Haas | 2010-01-07 02:41:16 | pgsql: Improve a couple of comments relating to large object snapshot |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-01-07 03:00:30 | Re: Testing with concurrent sessions |
Previous Message | Robert Haas | 2010-01-07 02:49:38 | Re: Testing with concurrent sessions |