Re: [HACKERS] OK, so culicidae is *still* broken - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] OK, so culicidae is *still* broken
Date
Msg-id 20170419153151.y5bfp4kdo377ycps@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] OK, so culicidae is *still* broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] OK, so culicidae is *still* broken  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 2017-04-19 10:15:31 -0400, Tom Lane wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane <tgl@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



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Interval for launching the table sync worker
Next
From: Maksim Milyutin
Date:
Subject: Re: [HACKERS] [PATCH] New command to monitor progression of longrunning queries