From: "Craig Ringer" <cr...@2ndquadrant.com>
I'm reasonably persuaded that there's a need for this, though IFEO (see
below) can be used at or after install-time as a workaround.
I see. And I also found it effective as another workaround to set the below
registry key. This disables ASLR for all executables, so it would be
It looks like your patch sets the msbuild equivalent of the
(http://msdn.microsoft.com/en-us/library/bb384887.aspx). Is this known
to work (or be silently ignored) back to Windows SDK 7.1? (I'll test it
today and see).
OK, I tried these versions at hand:
* Windows SDK 7.1, which happens to be associated with Visual Studio 2010 on
link.exe accepts /dynamicbase:no, which takes effect. Without
/dynamicbase:no, dumpbin /headers displays the lines:
8140 DLL characteristics
Terminal Server Aware
On the other hand, with /dynamicbase:no, the second line above disappeared.
* Visual Studio 2008 Express
link.exe seems to silently ignore /dynamicbase:no. dumpbin /headers does
not display "Dynamic base" regardless of whether /dynamicbase:no is
I don't think we need to worry about Force ASLR
(http://support.microsoft.com/kb/2639308) as it seems it only applies
when an application loads modules, unless an admin goes playing in the
Users facing this problem can work around it without code changes by
setting IFEO in the registry to disable ASLR for postgres.exe. See:
The problem is that users cannot discover the workaround. As more users use
PostgreSQL on Windows 8/2012, similar questions would be asked in
pgsql-general and pgsql-bugs.
It may be reasonable for EDB to consider releasing updated installers
that set IFEO flags to disable ASLR on postgres.exe .
Not all users use PostgreSQL built by EnterpriseDB, so I think
src\tools\msvc\build.bat should produce modules that are not affected by
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: