Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ). |
Дата | |
Msg-id | 603c8f071001061900l77475439l1f444cffc09b64a3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ). (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).
|
Список | pgsql-hackers |
On Wed, Jan 6, 2010 at 6:11 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: