“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 Hide

Porting applications to PostgreSQL has always been a task I personally liked but when somebody suddenly came to ask us to port “several hundred” terminal programs from Informix to PostgreSQL I was pretty overwhelmed. I have never seen such a big set of individual proprietary programs in one place.

The code which we are supposed to port is mostly consisting of Informix ESQL/C. The problem is only: You simply cannot go to every program and fix things once after the other. Changing 700 programs one after the other is simply impossible without either running out of time, manpower, or any other finite resource you can think of. So, obviously a traditional approach is not possible. The only approach to make things work within a reasonable timeframe is actually to change and extend the PostgreSQL precompiler to eat Informix code. As PostgreSQL is Open Source this is the best option and in my opinion the only possible solution to this problem. The funny thing is: That even writing countless precompiler extensions is still cheaper than paying for Informix support in the long run.

Hans-Jürgen Schönig, Porting to PostgreSQL Hide