Re: Memory leak with CREATE TEMP TABLE ON COMMIT DROP?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Eric Ridge <e_ridge(at)tcdi(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Memory leak with CREATE TEMP TABLE ON COMMIT DROP?
Date: 2014-06-13 01:27:02
Message-ID: 30781.1402622822@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Eric Ridge <e_ridge(at)tcdi(dot)com> writes:
> As best I can guess, Postgres has some kind of memory leak around (at least) temporary tables flagged to drop on commit. It's fairly easy to reproduce:

I don't see any memory leak with this example.

What I do see is the process's use of shared memory grows slowly until it
reaches 128MB (or whatever you've set shared_buffers to), and then stops.
This is normal behavior and has nothing to do with any memory leak: what
causes that is that top and related tools typically don't count shared
memory pages in a process's memory footprint until the process has
actually touched those pages. So as the process gradually touches more
and more of the shared buffers, its memory usage appears to climb, but
that's completely an illusion of the viewing tool. The important point
is the process's private memory usage, and that's not growing at all
AFAICS --- it's steady at a small number of megabytes.

Since you say you had an out-of-memory failure, you may well have had
some kind of leak in your original situation, but this test case isn't
reproducing it.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Grittner 2014-06-13 02:19:30 Re: max_connections reached in postgres 9.3.3
Previous Message John R Pierce 2014-06-12 23:55:27 Re: what does pg_activity mean when the database is stuck?