From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Roman Konoval <rkonoval(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Memory leak during delete with sequential scan |
Date: | 2014-09-12 02:17:57 |
Message-ID: | 30254.1410488277@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Roman Konoval <rkonoval(at)gmail(dot)com> writes:
> The simplified test which demonstrates this problem.
> $ psql -U postgres postgres
> psql (9.1.11, server 9.3.5)
> postgres=# create table t (i integer, t text);
> CREATE TABLE
> postgres=# insert into t select v,
> '01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789'
> || text(v) from generate_series(1,4000000) v;
> INSERT 0 4000000
> postgres=# \q
> restart postgres
> $ psql -U postgres postgres
> execute 500 times the following command in the same connection
> postgres=# delete from t where t = '';
I see absolutely no leak from this example in any existing release branch.
> This problem can be reliably reproducible only after restart of postgres.
That sounds suspiciously like what you are counting is a process's
accesses to shared memory. You did not say what shared_buffers setting
you're using, but if the "leak" tops out at something close to your
shared_buffers setting then that's almost certainly what it is.
In Linux systems you should generally be looking at RES minus SHR
not just RES to determine a process' private memory.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | srinivas.mca41 | 2014-09-12 03:19:03 | BUG #11404: Current PostgreSQL Databases Configuration |
Previous Message | Tom Lane | 2014-09-12 01:55:15 | Re: BUG #11402: Prepared statement cache invalidation and unknown types |