Re: [bug fix] Memory leak in dblink - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [bug fix] Memory leak in dblink
Date
Msg-id CAA4eK1J16KFhLm+gg=FndiaYwRD07Th5Kg7r3FBhK2KCaXN4jg@mail.gmail.com
Whole thread Raw
In response to Re: [bug fix] Memory leak in dblink  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [bug fix] Memory leak in dblink
Next
From: David Rowley
Date:
Subject: Re: Allowing NOT IN to use ANTI joins