Re: statement_timeout is not cancelling query

Robert Haas escribió:
> On Tue, Dec 15, 2009 at 11:02 AM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> > On Tue, Dec 15, 2009 at 3:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >>  This is an
> >> issue that other people have run into in the past, and I don't think
> >> we have a good solution.  I wonder if we should put some kind of a
> >> limit in place so that queries like this will at least fail relatively
> >> gracefully with an error message rather than taking down the box.
> >
> > Eh? That's exactly what's supposed to happen now. When malloc returns
> > 0 you're supposed to get a graceful error message and transaction
> > abort.
>
> 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.

Actually the real answer is that we can't spill the deferred trigger
queue to disk, so it consumes all memory. *That* is very much our own
shortcoming. The fact that this drove the operating system into
thrashing is just an expected (if undesirable) side effect. Greg is
right that if malloc returns 0 we act sanely, i.e. abort transaction and
release all the memory; Craig is right that having this happen is a good
thing. Whether or not this causes a lot of thrashing depends on the
situation, but that's an OS level problem, not Postgres'.

If we're to do anything about this, it is spilling the trigger queue so
it doesn't eat an unbounded amount of memory.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.