Re: Memory leak during delete with sequential scan

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