On Thu, Jun 25, 2015 at 12:22 PM, Noah Misch <noah@leadboat.com> wrote:
> On Wed, Jun 24, 2015 at 04:03:53PM +0900, Michael Paquier wrote:
>> On Wed, Jun 24, 2015 at 12:29 PM, Noah Misch <noah@leadboat.com> wrote:
>> > On Wed, Jun 24, 2015 at 10:06:00AM +0900, Michael Paquier wrote:
>> >> > On Tue, Sep 04, 2012 at 11:45:47PM -0400, Dave Vitek wrote:
>> >> >> LOG: could not reserve shared memory region (addr=0000000001410000) for child
>> >> >> 0000000000000F8C: 487
>> >> >> LOG: could not fork new process for connection: A blocking operation was
>> >> >> interrupted by a call to WSACancelBlockingCall.
>> >
>> >> So, it happens that it is still possible to hit this issue on at least
>> >> Win2k12 boxes (received some complaints about that) even if
>> >> RandomizedBaseAddress is disabled in build, as per a result of the
>> >> following thread:
>> >> http://www.postgresql.org/message-id/BD0D89EC2438455C9DE0DC94D36912F4@maumau
>> >
>> > That report led to the RandomizedBaseAddress="FALSE" commit, so the report was
>> > not based on such a build. If you have received complaints definitively
>> > involving a RandomizedBaseAddress="FALSE" build, that is novel evidence. If
>> > these complaints involved publicly-available binaries, which exact binaries
>> > (download URL)? If not, what do you know about how the binaries were built?
>>
>> They are not publicly available, but the build is done using the
>> community perl scripts with Visual 2008, with a slight difference
>> though in the VC spec file, AdditionalOptions includes /DLL to tell
>> the linker to build DLLs, but I don't think that it is much related to
>> the failure except if I am missing a crucial piece of information
>> regarding Visual.
>
> Here are some of the things I would try, then:
>
> - Reproduce it with postgresql.org official binaries.
> - Run "dumpbin /headers" on postgres.exe and every dll it links at startup,
> including dependencies. Compare to the corresponding data from
> postgresql.org official binaries.
> - Rebuild with VS2013 and see if the problem persists.
> - Identify the allocation(s) overlapping the region needed for shared memory.
I guess that it is the way to do it then. I will try with a build
compiled directly from the community sources and from those builds and
see if it is reproducible or not at least once. It may be possible
that the dll loaded by postgres.exe have an effect on it, but well
let's see with a configuration under memory pressure...
--
Michael