Re: statement_timeout is not cancelling query

On Tue, Dec 15, 2009 at 12:07 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Tue, Dec 15, 2009 at 4:16 PM, Robert Haas <robertmhaas(at)gmail(dot)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