On Wed, Mar 9, 2016 at 11:00 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > Note that running with overcommit_memory = 0 if you do start to run > out of memory, the oom killer will often kill the postmaster. This is > bad. If this happens make sure to kill all postgres children before > trying to restart the db, as starting a new postmaster with children > still running will instantly and permanently corrupt / destroy your > db. And even if it kills one of the "normal" backends (perhaps even the one responsible for some excessive allocations) it causes a PANIC, which is a crash and restart of the entire database service. It will usually do this on a reference to memory which appeared to be successfully allocated, which can be fairly confusing. With overcommit_memory = 2 you usually get just a FATAL error (loss of connection) on the one connection doing the memory allocation which puts things over the top, with a dump of space used by memory contexts in the log. > The eventual state you want is to be able to run with overcommit = 2 > and settings that prevent out of memory allocations. Agreed. > Note too that if you never seem to actually run out of memory, but get > allocation errors, it can also be a lack of file handles (I think > that's what caused it in the past for me. Been a while) Point being > that you can get a failure to allocate memory when there's plenty of > memory due to other settings on your server. Yes, I have seen that, too. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
