Re: psql leaks memory on query cancellation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Darafei Komяpa Praliaskouski <me@komzpa.net>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-12T17:44:53Z
Lists: pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes: > On 12 April 2018 at 18:26, Darafei "Komяpa" Praliaskouski <me@komzpa.net> wrote: >> Is it expected behavior (so I can have a look at something server returned >> somehow and it's kept there for me), or a plain leak? > This is totally normal behaviour for any C program. Well, it depends. On some platforms, malloc basically never gives back memory to the OS, but on glibc/Linux it does. What I see here, experimenting with a slightly-cut-down version of the example, is that if psql is allowed to finish the query normally then its memory usage according to "top" *does* go back down to very little at the end. But if one hits control-C partway through, it doesn't. 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.) In short, there might be something that could be improved here, but I've not dug into it enough to say for sure. BTW, I also notice that either psql or libpq seems to take a darn long time to release a several-GB-sized query result. That might be improvable as well. regards, tom lane
Commits
-
In libpq, free any partial query result before collecting a server error.
- bbec33c2d026 9.3.23 landed
- 3dd36aa4b36c 9.4.18 landed
- 2278e94ae941 9.5.13 landed
- 131f6a958360 9.6.9 landed
- d25c2ee9c038 11.0 landed
- d014b38df60f 10.4 landed