SRF memory leaks

Поиск
Список
Период
Сортировка
Искать
От
Neil Conway
Тема
SRF memory leaks
Дата
Msg-id
1203975130.31481.15.camel@dell.linuxdev.us.dell.com
Список
Дерево обсуждения
SRF memory leaks Neil Conway <neilc@samurai.com>
Re: SRF memory leaks Tom Lane <tgl@sss.pgh.pa.us>
Re: SRF memory leaks Neil Conway <neilc@samurai.com>
Re: SRF memory leaks Tom Lane <tgl@sss.pgh.pa.us>
Re: SRF memory leaks Neil Conway <neilc@samurai.com>
Re: SRF memory leaks Neil Conway <neilc@samurai.com>
Re: SRF memory leaks Neil Conway <neilc@samurai.com>
Re: SRF memory leaks Neil Conway <neilc@samurai.com>
Re: SRF memory leaks Tom Lane <tgl@sss.pgh.pa.us>
Re: SRF memory leaks Neil Conway <neilc@samurai.com>
Re: SRF memory leaks Tom Lane <tgl@sss.pgh.pa.us>
Attached is a patch that fixes the SRF memory leaks I recently reported
on -hackers[1]. The patch creates a distinct memory context for the
SRF's "multi_call_memory_ctx", and then deletes that context when the
SRF finishes. This ensures that any user allocations made in this
context are reclaimed. The patch also frees a TupleDesc that was leaked
in the per-query context when nodeFunctionscan was rescanned. Along the
way, it also fixes a leak in shutdown_MultiFuncCall() ("attinmeta" was
freed, but its palloc'd fields were not.)

It would be possible to allocate the TupleDesc in the multi-call memory
context, but it doesn't seem worth bothering about to me (since it would
require passing the context from the RSI down to the FuncCallContext). I
also didn't try to have multiple SRFs in the same subquery block use the
same context -- that seems like a lot of pain for little gain.

Comments welcome -- I think this fix should be applied to back branches.

-Neil

[1] http://markmail.org/message/45hekjinzl3e5i6q

В списке pgsql-patches по дате отправления
От: Peter Eisentraut
Дата:
Сообщение: Shlib exports file refactoring
От: Euler Taveira de Oliveira
Дата:
FAQ