Re: Is there a memory leak in commit 8561e48?
От | Peter Eisentraut |
---|---|
Тема | Re: Is there a memory leak in commit 8561e48? |
Дата | |
Msg-id | 4ab2aa26-5166-1a35-b89b-c5d73bf565b9@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Is there a memory leak in commit 8561e48? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Is there a memory leak in commit 8561e48?
|
Список | pgsql-hackers |
On 5/1/18 11:42, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> The memory leak can be fixed by adding a pfree(). > > That seems like an odd way to approach this. Why not just remove the > reset of _SPI_stack and _SPI_stack_depth, so as to subtract code rather > than adding it --- that is, make it actually work like you mistakenly > thought it did? If we're going to keep the stack in TopMemoryContext, > there's no need to thrash it on every transaction. Yes, that seems attractive. Are we concerned about the case where someone runs a very deeply nested SPI setup once in a session, creating a large stack allocation, which then persists for the rest of the session? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: