From: "Craig Ringer" <>
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 disliked.

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages

It looks like your patch sets the msbuild equivalent of the
( 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 my PC link.exe accepts /dynamicbase:no, which takes effect. Without /dynamicbase:no, dumpbin /headers displays the lines:

           8140 DLL characteristics
                  Dynamic base
                  NX compatible
                  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 specified.

I don't think we need to worry about Force ASLR
( 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 ASLR.


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to