On Tue, Dec 15, 2009 at 12:07 PM, Greg Stark <gsst...@mit.edu> wrote: > On Tue, Dec 15, 2009 at 4:16 PM, Robert Haas <robertmh...@gmail.com> wrote: >> I didn't know that, but it I think by the time malloc returns 0 >> usually other bad things are happening. I don't think that's really >> an answer. > > Only if, as Craig said and you disputed, you have overcommit enabled > or lots of swap.
I definitely dispute that. :-) I mean, typically what happens when you allocate a lot of memory is that everything else on the system that's not in active use gets pushed out of RAM to make room for the memory hog. So all of your file cache goes away and not-recently-accessed portions of other processes code and data segments get swapped out. The system becomes crushingly slow and unresponsive. On my laptop, for example, eventually as memory consumption increases you can't use Xwindows any more because all of those processes have been pushed out to disk to make room for the memory hog. Every time you move the mouse it faults all those pages back in to try to redraw the screen. But as soon as you stop it pushes them all back out again. It's difficult to reach the point where malloc actually fails because as swapping increases the activity of the system (including the runaway process) grinds almost to a halt. I'm not willing to wait that long for my transaction to fail. I suppose that I could fix this by getting rid of my swap partition altogether, but that seems a rather extreme solution, and it's certainly not the way most UNIX/Linux systems I run across are configured, if for no other reason than that the operating system configurator usually recommends creating one. Am I all wet here? I thought waiting for malloc to fail was usually considered a poor error recovery mechanism. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs