Thread: BUG #14050: "could not reserve shared memory region" in postgresql log

The following bug has been logged on the website:

Bug reference:      14050
Logged by:          Mathias Schuch
Email address:      mschuch@avaya.com
PostgreSQL version: 9.3.5
Operating system:   Windows 7
Description:

I see the following entries in the log file on customer site:

2016-03-16 14:44:27 EST LOG:  database system is ready to accept
connections
2016-03-16 14:44:27 EST LOG:  autovacuum launcher started
2016-03-16 14:45:27 EST LOG:  could not reserve shared memory region
(addr=0000000001BB0000) for child 00000000000004CC: error code 487
2016-03-16 14:45:27 EST LOG:  could not fork autovacuum worker process: A
blocking operation was interrupted by a call to WSACancelBlockingCall.


2016-03-16 14:45:28 EST LOG:  could not reserve shared memory region
(addr=0000000001BB0000) for child 000000000000047C: error code 487
2016-03-16 14:45:28 EST LOG:  could not fork autovacuum worker process: A
blocking operation was interrupted by a call to WSACancelBlockingCall.

I read in the release notes that this issue should be solved with 9.3.4 but
with 9.3.5 it isn't.

On Tue, Mar 29, 2016 at 09:38:04AM +0000, mschuch@avaya.com wrote:
> PostgreSQL version: 9.3.5
> Operating system:   Windows 7

> 2016-03-16 14:45:28 EST LOG:  could not reserve shared memory region
> (addr=0000000001BB0000) for child 000000000000047C: error code 487
> 2016-03-16 14:45:28 EST LOG:  could not fork autovacuum worker process: A
> blocking operation was interrupted by a call to WSACancelBlockingCall.
>
> I read in the release notes that this issue should be solved with 9.3.4 but
> with 9.3.5 it isn't.

We had not seen this on Windows 7.  From where did you download the PostgreSQL
binaries, or with which tools did you build them?  Which antivirus and/or
anti-malware software does this system use?

On 3/29/2016 2:38 AM, mschuch@avaya.com wrote:
> PostgreSQL version: 9.3.5


9.3.12 is the latest version of the 9.3 series, why are you messing with
a update released nearly 2 years ago thats been superseded 7 times ?

--
john r pierce, recycling bits in santa cruz

We use the PostgreSQL setup from EnterpriseDB. There is a McAfee VirisScan =
Enterprise 8.8 running on the system.


-----Urspr=FCngliche Nachricht-----
Von: Noah Misch [mailto:noah@leadboat.com]=20
Gesendet: Sonntag, 3. April 2016 22:58
An: Schuch, Mathias (Mathias) <mschuch@avaya.com>
Cc: pgsql-bugs@postgresql.org
Betreff: Re: BUG #14050: "could not reserve shared memory region" in postgr=
esql log

On Tue, Mar 29, 2016 at 09:38:04AM +0000, mschuch@avaya.com wrote:
> PostgreSQL version: 9.3.5
> Operating system:   Windows 7

> 2016-03-16 14:45:28 EST LOG:  could not reserve shared memory region
> (addr=3D0000000001BB0000) for child 000000000000047C: error code 487
> 2016-03-16 14:45:28 EST LOG:  could not fork autovacuum worker=20
> process: A blocking operation was interrupted by a call to WSACancelBlock=
ingCall.
>=20
> I read in the release notes that this issue should be solved with=20
> 9.3.4 but with 9.3.5 it isn't.

We had not seen this on Windows 7.  From where did you download the Postgre=
SQL binaries, or with which tools did you build them?  Which antivirus and/=
or anti-malware software does this system use?

On Mon, Apr 04, 2016 at 08:05:34AM +0000, Schuch, Mathias (Mathias) wrote:
> We use the PostgreSQL setup from EnterpriseDB. There is a McAfee VirisScan Enterprise 8.8 running on the system.

You could try updating to PostgreSQL 9.3.12 and disabling the antivirus
software.  I don't have a specific reason to expect those to help, but they're
relatively easy.

In your position, I would next instrument postgres.exe to log a memory map of
the child during pgwin32_ReserveSharedMemoryRegion().  That would show which
DLL created the address space collision.

I can't find the information how to enable this logging. Can tell me where =
to find this?

-----Urspr=FCngliche Nachricht-----
Von: Noah Misch [mailto:noah@leadboat.com]=20
Gesendet: Mittwoch, 6. April 2016 08:08
An: Schuch, Mathias (Mathias) <mschuch@avaya.com>
Cc: pgsql-bugs@postgresql.org
Betreff: Re: BUG #14050: "could not reserve shared memory region" in postgr=
esql log

On Mon, Apr 04, 2016 at 08:05:34AM +0000, Schuch, Mathias (Mathias) wrote:
> We use the PostgreSQL setup from EnterpriseDB. There is a McAfee VirisSca=
n Enterprise 8.8 running on the system.

You could try updating to PostgreSQL 9.3.12 and disabling the antivirus sof=
tware.  I don't have a specific reason to expect those to help, but they're=
 relatively easy.

In your position, I would next instrument postgres.exe to log a memory map =
of the child during pgwin32_ReserveSharedMemoryRegion().  That would show w=
hich DLL created the address space collision.

On 4/6/2016 2:07 AM, Schuch, Mathias (Mathias) wrote:
>> In your position, I would next instrument postgres.exe to log a memory map of the child during
pgwin32_ReserveSharedMemoryRegion(). That would show which DLL created the address space collision. 
>
> In your position, I would next instrument postgres.exe to log a memory map of the child during
pgwin32_ReserveSharedMemoryRegion(). That would show which DLL created the address space collision. 

by 'instrument' I believe he meant add appropriate logging statements to
the source code, and recompile postgres.  not an easy undertaking for an
end user.



--
john r pierce, recycling bits in santa cruz

[John, please use reply-all to keep thread participants on Cc.  Also, your
reply asserted that it was quoting from Mathias's message but instead bore two
identical copies of a paragraph I wrote.]

On Wed, Apr 06, 2016 at 03:41:09PM -0700, John R Pierce wrote:
> by 'instrument' I believe he meant add appropriate logging statements to the
> source code, and recompile postgres.  not an easy undertaking for an end
> user.

Correct.  I'm not seeing an easier way, unfortunately.