Robert Haas escribió: > On Tue, Dec 15, 2009 at 11:02 AM, Greg Stark <gsst...@mit.edu> wrote: > > On Tue, Dec 15, 2009 at 3:44 PM, Robert Haas <robertmh...@gmail.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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs