Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

On Mon, Jul 18, 2016 at 10:05 AM, Tom Lane wrote: > Jan Wieck writes: > > In the meantime, would it be appropriate to backpatch the double linking > > of memory context children at this time? I believe it has had plenty of > > testing in the 9.6 cycle to be

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

Merlin Moncure writes: > Hm, maybe, instead of trying to figure out if in a loop, set a > 'called' flag with each statement and only cache when touched the > second time. (If that's easier, dunno). Well, then you just guarantee to lose once. I think Jan's sketch of marking

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

Jan Wieck writes: > In the meantime, would it be appropriate to backpatch the double linking > of memory context children at this time? I believe it has had plenty of > testing in the 9.6 cycle to be sure it didn't break anything. I'm concerned about the ABI breakage risk from

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

On Mon, Jul 18, 2016 at 8:59 AM, Jan Wieck wrote: > > > On Mon, Jul 18, 2016 at 9:43 AM, Tom Lane wrote: >> >> Merlin Moncure writes: >> > BTW, while the fix does address the cleanup performance issue, it's >> > still the case that

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

On Mon, Jul 18, 2016 at 9:43 AM, Tom Lane wrote: > Merlin Moncure writes: > > BTW, while the fix does address the cleanup performance issue, it's > > still the case that anonymous code blocks burn up lots of resident > > memory (my 315k example I tested

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

Merlin Moncure writes: > BTW, while the fix does address the cleanup performance issue, it's > still the case that anonymous code blocks burn up lots of resident > memory (my 315k example I tested with ate around 8gb IIRC) when run > like this. My question is, if the pl/pgsql

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

On Sat, Jul 16, 2016 at 2:47 PM, Jan Wieck wrote: > On Tue, Jul 12, 2016 at 3:29 PM, Merlin Moncure wrote: >> >> I've noticed that pl/pgsql functions/do commands do not behave well >> when the statement resolves and frees memory. To be clear: >> >> FOR i in

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

BTW, here is the email thread about double-linking MemoryContext children patch, that Kevin at the end committed to master. https://www.postgresql.org/message-id/55F2D834.8040106%40wi3ck.info Regards, Jan On Sat, Jul 16, 2016 at 3:47 PM, Jan Wieck wrote: > > > On Tue, Jul

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

On Tue, Jul 12, 2016 at 3:29 PM, Merlin Moncure wrote: > I've noticed that pl/pgsql functions/do commands do not behave well > when the statement resolves and frees memory. To be clear: > > FOR i in 1..100 > LOOP > INSERT INTO foo VALUES (i); > END LOOP; > > ...runs

[HACKERS] DO with a large amount of statements get stuck with high memory consumption

I've noticed that pl/pgsql functions/do commands do not behave well when the statement resolves and frees memory. To be clear: FOR i in 1..100 LOOP INSERT INTO foo VALUES (i); END LOOP; ...runs just fine while BEGIN INSERT INTO foo VALUES (1); INSERT INTO foo VALUES (2); ...