Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial)

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial)
Дата
Msg-id CAHGQGwFgMeJj8MH4e-u7KfDXi+4MAahG_YDjxbhbWZDx_Shkkg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial)  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial)
Список pgsql-hackers
On Fri, Jun 5, 2015 at 12:39 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>
>
> On Thu, Jun 4, 2015 at 10:40 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>
>> On Mon, Jun 1, 2015 at 4:24 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>> > On Thu, May 28, 2015 at 9:09 PM, Michael Paquier
>> > <michael.paquier@gmail.com> wrote:
>> >> Since commit de768844, XLogFileCopy of xlog.c returns to caller a
>> >> pstrdup'd string that can be used afterwards for other things.
>> >> XLogFileCopy is used in only one place, and it happens that the result
>> >> string is never freed at all, leaking memory.
>>
>> That seems to be almost harmless because the startup process will exit
>> just after calling XLogFileCopy(). No?
>
>
> Yes that's harmless. My point here is correctness, prevention does not hurt
> particularly if this code path is used more in the future.

Why don't we call InstallXLogFileSegment() at the end of XLogFileCopy()?
If we do that, the risk of memory leak you're worried will disappear at all.

Regards,

-- 
Fujii Masao



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: RFC: Remove contrib entirely
Следующее
От: Robert Haas
Дата:
Сообщение: Re: RFC: Remove contrib entirely