Re: configurability of OOM killer - Mailing list pgsql-hackers

From Ron Mayer
Subject Re: configurability of OOM killer
Date
Msg-id 47A8DB09.6000803@cheapcomplexdevices.com
Whole thread Raw
In response to Re: configurability of OOM killer  (Decibel! <decibel@decibel.org>)
Responses Re: configurability of OOM killer  (Decibel! <decibel@decibel.org>)
Re: configurability of OOM killer  ("Dawid Kuroczko" <qnex42@gmail.com>)
List pgsql-hackers
Decibel! wrote:
> 
> Yes, this problem goes way beyond OOM. Just try and configure
> work_memory aggressively on a server that might see 50 database
> connections, and do it in such a way that you won't swap. Good luck.

That sounds like an even broader and more difficult problem
than managing memory.

If you have 50 connections that all want to perform large sorts,
what do you want to have happen?
 a) they each do their sorts in parallel with small amounts    of memory for each; probably all spilling to disk? b)
theyeach get a big chunk of memory but some have to    wait for each other? c) something else?
 

Seems (a)'s already possible today with setting small work_mem.
Seems (b)'s already possible today with a larger work_mem and
pg_pool.

Stepping back from the technical details, what do you think
should happen.   (though perhaps it should be taken to a different
thread)


pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file
Next
From: Ron Mayer
Date:
Subject: Re: Feature Freeze Date for Next Release