Linux kernel patch

“out of memory” — this is definitely not something what you really want to see in any of your programs at any point in time. Especially for a database server such as PostgreSQL it can be pretty nasty if you run out of memory. If the error is detected by the database itself, it is basically not a problem at all and PostgreSQL will know how to deal with it.

However, what happens if you are NOT alone on your system? What if other processes eat up your database’s RAM? On Linux you can in some cases get in conflict with the so called “OOM-killer”. This is a feature of the operating system which basically kills a process which it feels is “best”. This should free up some memory – but you will also lose one or the other process on your system.

What if one of the processes killed happens to be PostgreSQL? In many cases this is exactly what you want to avoid. Currently there is no way to tell the Linux kernel which processes are potential candidates for some memory killing-party. This was an issue for some customers – in a professional database application it can be essential to make sure that the central service is always alive. In exchange you may sacrifice one or the other not so important process just to make sure that the central survive will also do its job as expected.

To fix the problem with the Linux kernel we hacked up a small page allowing users to teach the operating system core which processes to kill when running out of memory. Administrators can now define on which order the system is allowed to kill processes in the (hopefully rare) case of real emergency.

This small little feature can dramatically increase the availability of your database infrastructure.

If you are interested in testing this patch, check out our download page for more details.

No tags