| From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: psql leaks memory on query cancellation |
| Date: | 2018-04-12 18:23:29 |
| Message-ID: | 6758831e-2871-2115-ea53-f2d4fbf02f52@sigaev.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I imagine that this indicates that control-C processing allocates some
> memory it doesn't free, resulting in an "island" up at the end of memory
> that prevents glibc from releasing all the free memory it's got. Whether
> that's an actual leak, or just memory we're holding onto in hopes of
> reusing it, isn't clear. (valgrind might be useful.)
malloc could request memory from kernel by two ways: sbrk() and mmap(),
first one has described problem, mmap hasn't. It's described in
mallopt(3) in section M_MMAP_THRESHOLD, to test that try to repeat test
with MALLOC_MMAP_THRESHOLD_ environment set to 8192.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-04-12 18:25:25 | Re: crash with sql language partition support function |
| Previous Message | Jacob Champion | 2018-04-12 18:22:45 | Re: submake-errcodes |