Crash with old Windows on new CPU

From: Christian Ullrich <chris(at)chrullrich(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Crash with old Windows on new CPU
Date: 2016-02-12 16:24:24
Message-ID: n9l0vo$koa$
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


I just found a compatibility issue when I was migrating an elderly VM to
a new host. The VM is running Windows Server 2008 SP2, and it has the
EDB build of PostgreSQL 9.4.5 on it. (9.4.6 behaves the same.) It is
also not dependent on running in a VM; it would fail on the hardware as

Backends (and possibly other processes) crash at the slightest
provocation, such as "SELECT * FROM pg_stat_activity;" or VACUUM. The
log says either "exception 0xC0000005" (segfault) or "exception
0xC000001D" (illegal instruction).

The interesting reason: The old host had a Core-generation CPU, which
does not support the AVX2 instruction set. The new one has a
Haswell-generation one, and this one does. The EDB distribution of 9.4
was built with the Visual Studio 2013 compiler, whose CRT (aka libc) has
a bug where it uses AVX2 instructions if the *CPU* supports them, but
does not care whether the *OS* does, and 2008 doesn't. That support was
added in SP1 for 7/2008R2.

There is a workaround, see
It consists of a single function call, required only if the OS does not
support AVX2.

I just tried it, and it appears to work. If there is any interest in
fixing this, I'll be happy to prepare a patch. (Where would be the best
place to put a function call from <math.h> that has to be done during
startup of each server process, on Windows only?)

Otherwise, it may be time to update the manual (15.6 Supported
Platforms) where it says PostgreSQL "can be expected to work on these
operating systems: [...] Windows (Win2000 SP4 and later), [...]".
Perhaps we could add "except Windows before 7 SP1/2008R2 SP1 when
running in x64 mode on Intel CPUs introduced after May 2013 (Haswell and



Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-12 16:29:44 Re: GinPageIs* don't actually return a boolean
Previous Message Teodor Sigaev 2016-02-12 16:15:59 Re: GinPageIs* don't actually return a boolean