Re: [bug fix] Memory leak in dblink

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, MauMau <maumau307(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [bug fix] Memory leak in dblink
Date: 2014-06-11 05:52:31
Message-ID: CAA4eK1J16KFhLm+gg=FndiaYwRD07Th5Kg7r3FBhK2KCaXN4jg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 11, 2014 at 10:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2014-06-11 08:53:03 Re: Allowing NOT IN to use ANTI joins
Previous Message Tom Lane 2014-06-11 05:16:29 Re: [bug fix] Memory leak in dblink