Re: psql leaks memory on query cancellation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: psql leaks memory on query cancellation
Date
Msg-id 8043.1523555093@sss.pgh.pa.us
Whole thread Raw
In response to Re: psql leaks memory on query cancellation  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: psql leaks memory on query cancellation
Re: psql leaks memory on query cancellation
List 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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Covering GiST indexes
Next
From: Andrew Gierth
Date:
Subject: Re: submake-errcodes