PostgreSQL Meltdown

Spectre and Meltdown have caused severe alarm in recent days. You may have read about up to 30% impact on PostgreSQL databases, which I believe to be overstated because of misunderstandings in the media. Let’s dig into this in more detail.

TL;DR Summary: no PostgreSQL patch required, -7% performance hit

In response to these new security threats various OS patches have been released. Various authors have published benchmarks around these and they have, in some cases, stated worst-case measurements as impact measurements. For example: stating a 30% hit when, in fact, we are seeing a 7% hit on a busy server. Regrettably, it looks to me like some people outside the PostgreSQL community have spread this news as a problem for PostgreSQL, without clearly stating the workload measured, or that it could affect all types of database about the same amount.
So let’s back up a little: these patches affect the OS – there is no specific vulnerability in PostgreSQL and crucially, there is no security patch planned. Yup, that’s right, no patch.

Why? The published exploits require access to the OS, which is not possible through PostgreSQL except where the user has SuperUser access through the use of untrusted PL languages, such as PL/PerlU. So in general, there is no attack vector through user access to PostgreSQL databases.
However, there is a noticeable CPU impact because of generalized patches being applied at OS level.

These will have a greater impact on CPU-bound database requests, so we expect the impact on I/O bound transactional workloads to be much smaller. The impact will be more noticeable on a server that is already heavily loaded than on a lightly loaded server, so the impact may vary as your workload increases/decreases. There is a small increase in latency.

Patches are now available for Red Hat and Ubuntu that allow you to enable the Page Table Isolation feature (pti:on).

We have performed a series of benchmarking tests to have a better idea on the real impact that can be caused by the patches. In general, a drop of around 7% on the number of transactions per second (TPS) was observed on standard pgbench tests on PostgreSQL 10. The impact is roughly the same on both smaller and larger systems.
http://www.postgresql.org/docs/current/static/pgbench.html

OS security patches will need to be applied. Now, the big question is whether we should enable PTI or not? If PTI is disabled the 7% drop in performance goes away to almost nothing, maybe 1% or less. Whilst this might prove tactically advantageous, 2ndQuadrant would never recommend or endorse disabling PTI – use at your own risk!

Known exploits require attackers to be able to execute arbitrary code on the machine – the chance of this happening can be minimised by using a fully locked down application and/or using an SQLFirewall, like the one available to 2ndQuadrant Support Customers.

References:
http://en.wikipedia.org/wiki/Kernel_page-table_isolation
Hackers Discussion on PostgreSQL Hackers mailing list