From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: OK, so culicidae is *still* broken |
Date: | 2017-04-19 15:31:51 |
Message-ID: | 20170419153151.y5bfp4kdo377ycps@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-04-19 10:15:31 -0400, Tom Lane wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Maksim Milyutin | 2017-04-19 16:41:12 | Re: [PATCH] New command to monitor progression of long running queries |
Previous Message | Petr Jelinek | 2017-04-19 15:30:23 | Re: Interval for launching the table sync worker |