* Magnus Hagander wrote:
I did notice the #ifdef's are actually different in the header and body
section of the patch, which seems wrong. I used the one from the actual
implementation (_M_AMD64) for the header includes as, and also merged the
#ifdef's together to a single #if in each section.
On Wed, Mar 9, 2016 at 5:48 AM, Christian Ullrich
wrote:
> * Peter Eisentraut wrote:
>
> On 2/12/16 11:24 AM, Christian Ullrich wrote:
>>
>
> Otherwise, it may be time to update the manual (15.6 Supported
>>> Platforms) where it says PostgreSQL "can be expected to work on
* Magnus Hagander wrote:
On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich
wrote:
* Magnus Hagander wrote:
How does this work wrt mingw, though? Do we have the same problem there?
AIUI this code can never run on mingw, correct?
Not unless mingw defines _MSC_VER.
Magnus Hagander wrote:
> On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich
> wrote:
> > And apparently not a single one with VS 2013. OK, I'll see what I can do
> > about setting some up soonish, at least with (server) 2008 and (client) 7.
> > FWIW, I have a local build of
On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich
wrote:
> * Magnus Hagander wrote:
>
> On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich
>> wrote:
>>
>
> On February 13, 2016 4:10:34 PM Tom Lane wrote:
>>>
>>
> I'm also
* Magnus Hagander wrote:
On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich
wrote:
On February 13, 2016 4:10:34 PM Tom Lane wrote:
I'm also suspicious of the "#if _MSC_VER == 1800" tests, that is,
the code compiles on *exactly one* MSVC version.
On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich
wrote:
> On February 13, 2016 4:10:34 PM Tom Lane wrote:
>
> > Christian Ullrich writes:
> >> * Robert Haas wrote:
> >>> Thanks for the report and patch. Regrettably I haven't
* Peter Eisentraut wrote:
On 2/12/16 11:24 AM, Christian Ullrich wrote:
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
On 2/12/16 11:24 AM, Christian Ullrich wrote:
> 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
Christian Ullrich 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
On February 13, 2016 4:10:34 PM Tom Lane wrote:
> Christian Ullrich 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
>>>
Tom Lane wrote:
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.
* From: Christian Ullrich
> On February 13, 2016 4:10:34 PM Tom Lane wrote:
>
> > Christian Ullrich writes:
> > 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
On 13 February 2016 at 23:45, Christian Ullrich
wrote:
>
> > 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?
>
> The CRT version is tied to the compiler
Hello,
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
* Robert Haas wrote:
On Fri, Feb 12, 2016 at 7:26 PM, Christian Ullrich wrote:
startup_hacks(), I think. Proposed patch attached.
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
* Christian Ullrich wrote:
Backends (and possibly other processes) crash at the slightest
provocation, such as "SELECT * FROM pg_stat_activity;" or VACUUM. The
log says either "exception 0xC005" (segfault) or "exception
0xC01D" (illegal instruction).
The interesting reason: The old
17 matches
Mail list logo