Re: [HACKERS] Another nasty cache problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Another nasty cache problem
Дата
Msg-id 28325.949597221@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Another nasty cache problem  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Ответы Re: [HACKERS] Another nasty cache problem  ("Oliver Elphick" <olly@lfix.co.uk>)
Re: [HACKERS] Another nasty cache problem  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Список pgsql-hackers
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> Note that there is still plenty of swap space. The 128Mb number seems to be
> more than a coincidence (how to prove?)

The majority of Unix systems have a process size limit kernel parameter,
which is normally set to less than the amount of available swap space
(you don't want a single process running wild to chew up all your swap
and make other stuff start failing for lack of swap...)  Check your
kernel parameters.

It sounds to me like the backend has hit the size limit and is not
reacting gracefully to failure of malloc() to allocate more space.
It ought to exit with an elog(FATAL), probably.  Sigh, time to take
another pass through the code to cast a suspicious eye on everyplace
that calls malloc() directly.

There's a separate question about *why* such a simple query is chewing
up so much memory.  What query plan does EXPLAIN show for your test
query?

You said this was with current sources, right?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: [HACKERS] Parser/planner and column aliases
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Parser/planner and column aliases