Roman Konoval <rkonoval@gmail.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
