Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken)
Date
Msg-id 22632.1496770035@sss.pgh.pa.us
Whole thread Raw
In response to Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 6, 2017 at 12:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> By definition, the address range we're trying to reuse worked successfully
>> in the postmaster process.  I don't see how forcing a specific address
>> could do anything but create an additional risk of postmaster startup
>> failure.

> If the postmaster picked an address where other things are unlikely to
> get loaded, then that would increase the chances of child processes
> finding it available, wouldn't it?

But how would we know that a particular address range is more unlikely
than others to have a conflict?  (And even if we do know that, what
happens when there is a conflict anyway?)  I sure don't want to be in
the business of figuring out what to use across all the different Windows
versions there are, to say nothing of the different antivirus products
that might be causing the problem.

Also, the big picture here is that we ought to be working towards allowing
our Windows builds to use ASLR; our inability to support that is not
something to be proud of in 2017.  No predetermined-address scheme is
likely to be helpful for that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] inconsistent application_name use in logical workers
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Should we standardize on a type for signal handlerflags?