Request a Demo
Home   >   mailing lists

Re: Curing plpgsql's memory leaks for statement-lifespan values - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Curing plpgsql's memory leaks for statement-lifespan values
Date
Msg-id CAFiTN-uLBa3KOUUXGGWn9rxXgkc0MkBCJ4jKeon7p84+qEqw2A@mail.gmail.com
Whole thread
In response to Re: Curing plpgsql's memory leaks for statement-lifespan values  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Tree view

On Sun, Jul 24, 2016 at 12:40 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
In short, why do you think
it is better to create a new context rather than using "SPI Exec"?

I think life span of the memory allocated from "SPI Exec" is only within "Executor", and after that SPI_Exec
will be reset. But many places we need such memory beyond "Executor"(including one which is reported in above issue).

If we see below example of exec_stmt_dynexecute.
exec_stmt_dynexecute

{

....

querystr = pstrdup(querystr);

SPI_Execute --> inside this SPI_Exec context will be reset.

After this querystr is being used in this function.

}

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]
Next
From: Tom Lane
Date:
Subject: Re: Curing plpgsql's memory leaks for statement-lifespan values