Re: Memory leaks
От | Tom Lane |
---|---|
Тема | Re: Memory leaks |
Дата | |
Msg-id | 700.1035380936@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Memory leaks (Greg Copeland <greg@CopelandConsulting.Net>) |
Ответы |
Re: Memory leaks
|
Список | pgsql-hackers |
Greg Copeland <greg@copelandconsulting.net> writes: > Okay. I've started looking at plpython to better understand it's memory > needs. I'm seeing a mix of mallocs and PLy_malloc. The PLy version is > basically malloc which also checks and reports on memory allocation > errors. Anyone know if the cases where malloc was used was purposely > done so for performance reasons or simply the flavor or the day? Probably either oversight or the result of different people's different coding styles. > I thinking for starters, the plpython module could be normalized to use > the PLy_malloc stuff across the board. Then again, I still need to > spend some more time on it. ;) Consistency is good. What I'd wonder about, though, is whether you shouldn't be using palloc ;-). malloc, with or without a PLy_ wrapper, doesn't provide any leverage to help you get rid of stuff when you don't want it anymore. >>> Well, the thing that really got my attention is that dmalloc is >>> reporting frees on null pointers. >> >> AFAIK that would dump core on many platforms (it sure does here...), I have to take that back: I was thinking about pfree() not free(). The ANSI C spec says that free(NULL) is a legal no-op, and there are just a few ancient C libraries (perhaps none anymore) where it'll crash. I tend to do "if (ptr) free(ptr)" from force of habit, but I notice that psql (among other places) relies heavily on the ANSI behavior. It's probably pointless to try to convince people to change that coding style. regards, tom lane
В списке pgsql-hackers по дате отправления: