On 2017-04-19 10:15:31 -0400, Tom Lane wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> 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. > > Right, but Andres' point is that we should make an effort to undo that > hack and instead allow ASLR to happen. Not just because it's allegedly > more secure, but because we may have no choice in future Windows versions.
FWIW, I think it *also* might make us more secure, because addresses in the postgres binary won't be predictable anymore. Since most of the windows binaries are built by one source, that's some advantage on its own. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers