Re: [bug fix] Memory leak in dblink

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [bug fix] Memory leak in dblink
Дата
Msg-id CAA4eK1J16KFhLm+gg=FndiaYwRD07Th5Kg7r3FBhK2KCaXN4jg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [bug fix] Memory leak in dblink  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Jun 11, 2014 at 10:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > In some cases like for handling exceptions in plpgsql, PG_CATCH()
> > is used to handle the exception and then take an appropriate action
> > based on exception, so in some such cases it might be right to free
> > the context memory depending on situation.
>
> Robert's point is that the only safe way to suppress an error is to
> do a (sub)transaction rollback.  That will take care of cleaning up
> appropriate memory contexts, along with much else.  I don't see the
> value of adding any single-purpose cleanups when they'd just be
> subsumed by the transaction rollback anyhow.

Agreed in general there won't be need of any such special-purpose
cleanups and that's the main reason I have mentioned upthread to
remove context cleanup from PG_CATCH(), however for certain
special case where some situation want to allocate memory in
context higher level than transaction to retain data across
transaction boundary, it might be needed.  This is just a hypothetical
scenario came to my mind and I am not sure if there will be any 
actual need for such a thing.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [bug fix] Memory leak in dblink
Следующее
От: David Rowley
Дата:
Сообщение: Re: Allowing NOT IN to use ANTI joins