| 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: | Whole Thread | Raw Message | 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 |