Re: [HACKERS] OK, so culicidae is *still* broken

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] OK, so culicidae is *still* broken
Дата
Msg-id 20170419153151.y5bfp4kdo377ycps@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] OK, so culicidae is *still* broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] OK, so culicidae is *still* broken
Список 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 по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] Interval for launching the table sync worker
Следующее
От: Maksim Milyutin
Дата:
Сообщение: Re: [HACKERS] [PATCH] New command to monitor progression of longrunning queries