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?
> I am wondering if Perhaps we could do better than what we have now
> with a retry logic in the thread fork loop as it seems like a stopover
> to use a non-NULL lpBaseAddress in MapViewOfFileEx to make the address
> selection more random as this base address selection would be
> system-dependent.
I don't understand exactly what you're proposing here. Are you proposing to
retry backend creation after a child can't reattach to shared memory? That is
better than a user-facing failure, but let's start with a diligent attempt to
root-cause the complaints you have received.