Re: Crash with old Windows on new CPU

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christian Ullrich <chris(at)chrullrich(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Crash with old Windows on new CPU
Date: 2016-02-13 15:10:29
Message-ID: 20699.1455376229@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christian Ullrich <chris(at)chrullrich(dot)net> writes:
> * Robert Haas wrote:
>> Thanks for the report and patch. Regrettably I haven't the Windows
>> knowledge to have any idea whether it's right or wrong, but hopefully
>> someone who knows Windows will jump in here.

> In commitfest now.

FWIW, I'm a tad suspicious of the notion that it's our job to make this
case work. How practical is it really to run a Windows release on
unsupported-by-Microsoft hardware --- aren't dozens of other programs
going to have the same issue?

I'm also suspicious of the "#if _MSC_VER == 1800" tests, that is,
the code compiles on *exactly one* MSVC version. Maybe that's actually
what's needed, but it sure looks fishy. And what connection does the
build toolchain version have to the runtime environment anyway?

Likewise, how can we know that !IsWindows7SP1OrGreater() is the exactly
right runtime test?

Lastly, I'd like to see some discussion of what side effects
"_set_FMA3_enable(0);" has ... I rather doubt that it's really
a magic-elixir-against-crashes-with-no-downsides. That would
give us some context to estimate the risks of this code executing
when it's not really needed. Without that, I'd be worried that
this cure is worse than the disease because it breaks cases that
weren't broken before.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2016-02-13 15:13:55 Re: Defaults for replication/backup
Previous Message Tom Lane 2016-02-13 14:54:07 Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.