From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Dave Vitek <dvitek(at)grammatech(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, v-seishi(at)microsoft(dot)com |
Subject: | Re: Re: windows 8 RTM compatibility issue (could not reserve shared memory region for child) |
Date: | 2015-06-25 03:22:20 |
Message-ID: | 20150625032220.GA603717@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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(at)leadboat(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | hunkaverage | 2015-06-25 06:07:20 | BUG #13468: System hijacked by PostgreSQL user |
Previous Message | David G. Johnston | 2015-06-25 00:49:25 | Re: BUG #13465: multi update query use CTE, result & plan not equal, BUG? |