How 3.6 nearly broke PostgreSQL

> Possibly even worse is that preempting the PostgreSQL dispatcher process — also more likely with Mike's patch — can slow the flow of tasks to all PostgreSQL worker processes; that, too, will hurt performance.
The thing you could describe as a dispatcher, the "postmaster" process, which forks to create individual backends after receiving a connection requests doesn't do any relevant locking. So preemting it should be mostly harmless.
There are other processes though which might have something like the effect described above. Namely the 'wal writer', 'checkpointer' (9.2+, included in bgwriter before) and bgwriter processes. Especially if you have a write intensive concurrent workload interactions between individual connection backends and the wal writer can get contended. So its somewhat likely that preemption might get painful there.

Postgres is *far* from the only application doing its own spinlock implementation and contending on the locks every now and then. I am pretty sure that if the patch had made its way into 3.6 more performane regression reports would have come in.