Re: [HACKERS] Another nasty cache problem

Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)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