On 05/09/2012 10:01 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> The attached one-liner seems to plug up the majority (although not quite >> all) of the leakage. > > Looks sane to me. Are you planning to look for the remaining leakage?
Actually, now I'm not so sure there really are any other leaks. The last test I ran, on 9.1 with the original data and plpgsql function, grew to: VIRT RES SHR 540m 327m 267m but then stabilized there through the end of the query, which successfully returned: count ---------- 28847766 (1 row) This was with: report_log=# show shared_buffers; shared_buffers ---------------- 256MB (1 row) report_log=# show work_mem; work_mem ---------- 16MB (1 row) So I think those memory usage numbers look reasonable. The bug appears to go back through 8.4 -- kind of surprising no one has complained before. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
