On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2017-04-15 17:24:54 -0400, Tom Lane wrote: >>> I wonder whether we could work around that by just destroying the created >>> process and trying again if we get a collision. It'd be a tad >>> inefficient, but hopefully collisions wouldn't happen often enough to be a >>> big problem. > >> That might work, although it's obviously not pretty. We could also just >> default to some out-of-the-way address for MapViewOfFileEx, that might >> also work. > > Could be. Does Microsoft publish any documentation about the range of > addresses their ASLR uses? >
I have look around to find some information to see if there is any such address range which could be used for our purpose. I am not able to see any such predictable address range. You might want to read the article [1] especially the text around "What is the memory address space range in virtual memory map where system DLLs and user DLLs could load?" It seems to indicate that there is no such address unless I have misunderstood it. I don't deny the possibility of having such an address range, but I could not find any info on the same. > Obviously, any such fix would be a lot more likely to be reliable in > 64-bit machines. There's probably not enough daylight to be sure of > making it work in 32-bit Windows, so I suspect we'd need some retry > logic anyway for that case. > Yeah, that kind of thing can work assuming we don't get conflicts too often, but it could be possible that conflicts are not reported from ASLR enabled environments because of commit 7f3e17b4. [1] - https://blogs.msdn.microsoft.com/winsdk/2009/11/30/how-to-disable-address-space-layout-randomization-aslr/ -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
