Re: BUG #6763: Severe memory leak with arrays and hstore

On 07/26/2012 09:55 PM, luben karavelov wrote:

> Ok, I will do the procedure again with taking notes on each step.

Thankyou for taking the time to do this in detail.

> First, here are the results of the queries you asked:
> count | to_char
> ---------+-----------
> 1257262 | 2.26

> pg_size_pretty
> ----------------
> 264 MB

OK, none of that looks obviously insanely huge to me. That's a lot of
hstores, but with your query I wouldn't expect them to all sit around in
memory, and nothing individually is particularly huge.

> Also there are max of 34 rows per user_id in old_prefs

Thanks, I forgot to ask that. Again, nothing particularly big.

> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> postgres 19121 0.0 0.0 2266944 3448 ? Ss 15:23 0:00 postgres: pg pg 10.0.2.71(51734) idle
> postgres 19121 0.8 7.1 3081772 582712 ? Ss 15:23 0:02 postgres: pg pg 10.0.2.71(51734) idle
> postgres 19121 1.1 8.5 3176164 697444 ? Ss 15:23 0:05 postgres: pg pg 10.0.2.71(51734) idle
> postgres 19121 0.7 9.6 3210224 791404 ? Ss 15:23 0:08 postgres: pg pg 10.0.2.71(51734) idle
> postgres 19121 0.9 10.8 3277412 889860 ? Ss 15:23 0:11 postgres: pg pg 10.0.2.71(51734) idle
> postgres 19121 0.9 11.5 3277412 945560 ? Ss 15:23 0:15 postgres: pg pg 10.0.2.71(51734) idle
> postgres 19121 1.2 16.2 3736968 1331796 ? Ss 15:23 0:20 postgres: pg pg 10.0.2.71(51734) idle

> 1. Backend does not free allocated memory between transactions.
> 2. Rolled back transactions also leak memory.
> 3. Leaked memory is not linear to work done - 2 transactions with 200k keys will leak less than 1 transaction with 400k keys

Ouch. Sure looks like a leak to me, yeah.

Thankyou for taking the time to do this. It's common to see "leaks"
reported here that are really just queries that require lots of memory,
so the first response tends to be somewhat cautious.

This doesn't look like one of those reports.

I don't know if I can be much use with the actual tracking down of the
leak, but there certainly appears to be one, and you've provided a
pretty clear illustration of it.

--
Craig Ringer