Re: psql leaks memory on query cancellation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: psql leaks memory on query cancellation
Дата
Msg-id 8043.1523555093@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: psql leaks memory on query cancellation  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: psql leaks memory on query cancellation  (Teodor Sigaev <teodor@sigaev.ru>)
Re: psql leaks memory on query cancellation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Covering GiST indexes
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: submake-errcodes