Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On 8/19/16 10:42 AM, Tom Lane wrote: It appeared to me after collecting some stats about the functions present in the regression tests that for larger functions, the extra space eaten is just some small multiple (like 2x-3x) of the function body string length. So it's not *that* much data, even

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Jim Nasby writes: > On 7/25/16 1:50 PM, Tom Lane wrote: >> There's a glibc-dependent hack in aset.c that reports any >> plpgsql-driven palloc or pfree against a context named "SPI Proc", as >> well as changes in pl_comp.c so that transient junk created during initial >>

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On 7/25/16 1:50 PM, Tom Lane wrote: There's a glibc-dependent hack in aset.c that reports any plpgsql-driven palloc or pfree against a context named "SPI Proc", as well as changes in pl_comp.c so that transient junk created during initial parsing of a plpgsql function body doesn't end up in the

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Pavel Stehule writes: > I am sending a review of this patch: > ... > I'll mark this patch as ready for commiter Pushed, thanks for the review. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

2016-08-10 11:25 GMT+02:00 Pavel Stehule : > Hi > > 2016-07-27 16:49 GMT+02:00 Tom Lane : > >> Robert Haas writes: >> > On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote: >> >> I suppose that a fix based on

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Hi 2016-07-27 16:49 GMT+02:00 Tom Lane : > Robert Haas writes: > > On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote: > >> I suppose that a fix based on putting PG_TRY blocks into all the > affected > >> functions might be simple

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Robert Haas writes: > On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote: >> I suppose that a fix based on putting PG_TRY blocks into all the affected >> functions might be simple enough that we'd risk back-patching it, but >> I don't really want to go

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote: > I suppose that a fix based on putting PG_TRY blocks into all the affected > functions might be simple enough that we'd risk back-patching it, but > I don't really want to go that way. try/catch blocks aren't completely free,

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Alvaro Herrera writes: > Tom Lane wrote: >> Although this is in principle a bug fix, it's invasive enough that I'd >> be pretty hesitant to back-patch it, or even to stick it into HEAD >> post-beta. I'm inclined to sign it up for the next commitfest instead. > Do we

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Alvaro Herrera wrote: > Tom Lane wrote: > > > Although this is in principle a bug fix, it's invasive enough that I'd > > be pretty hesitant to back-patch it, or even to stick it into HEAD > > post-beta. I'm inclined to sign it up for the next commitfest instead. > > Do we have a backpatchable

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Tom Lane wrote: > Although this is in principle a bug fix, it's invasive enough that I'd > be pretty hesitant to back-patch it, or even to stick it into HEAD > post-beta. I'm inclined to sign it up for the next commitfest instead. Do we have a backpatchable fix for the reported problem? If so,

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Attached is a draft patch for creating statement-level temporary memory contexts in plpgsql. It creates such contexts only as needed, and there are a lot of simpler plpgsql statements that don't need them, so I think the performance impact should be pretty minimal --- though I've not tried to

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Sun, Jul 24, 2016 at 9:17 PM, Tom Lane wrote: > Amit Kapila writes: > >> Wouldn't it be better, if each nested sub-block (which is having an >> exception) has a separate "SPI Proc", "SPI Exec" contexts which would >> be destroyed at sub-block end

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Amit Kapila writes: > On Fri, Jul 22, 2016 at 4:32 AM, Tom Lane wrote: >> The problem is that exec_stmt_dynexecute() loses control to the error >> thrown from the bogus command, and therefore leaks its "querystr" local >> variable --- which is not

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Sun, Jul 24, 2016 at 12:40 PM, Amit Kapila 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

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Fri, Jul 22, 2016 at 4:32 AM, Tom Lane wrote: > In > https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com > it was pointed out that you could get an intra-function-call memory leak > from something like > > LOOP > BEGIN >

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Craig Ringer writes: > On 22 July 2016 at 13:24, Craig Ringer wrote: >> I suggest that in cassert builds, or maybe just CACHE_CLOBBER_ALWAYS, the >> context is reset after each call even when not cleaning up after an error. >> That'll help catch

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On 22 July 2016 at 13:24, Craig Ringer wrote: > > On 22 July 2016 at 07:02, Tom Lane wrote: > >> In >> >> https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com >> it was pointed out that you could get an intra-function-call

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On 22 July 2016 at 07:02, Tom Lane wrote: > In > > https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com > it was pointed out that you could get an intra-function-call memory leak > from something like > > LOOP > BEGIN >

[HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

In https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com it was pointed out that you could get an intra-function-call memory leak from something like LOOP BEGIN EXECUTE 'bogus command'; EXCEPTION WHEN OTHERS THEN END;