Обсуждение: PG 924, Windows 2012, error code 487
Hi,
Since moving to PG 9.2.4 we are facing many connection refusals from PG
Mainly on Windows 8, Server 2012 and Server2012R2.
Error …
could not fork new process for connection: A blocking operation was interrupted by a call to WSACancelBlockingCall
Sometimes it even fails the AUTOVACUM process.
Thanks
Danny
On 01/12/2014 06:07 AM, Abraham, Danny wrote: > Hi, > > Since moving to PG 9.2.4 we are facing many connection refusals from PG > > Mainly on Windows 8, Server 2012 and Server2012R2. > > Error … > > could not fork new process for connection: A blocking operation was > interrupted by a call to WSACancelBlockingCall Are the servers on the Windows versions you mention or the clients or both? Where is this error showing up, the Windows or Postgres logs? What does the other log show? Is there anything preceding the above that might shed light? Are the connections across a network and if so is there a firewall between the clients and server(s)? > > Sometimes it even fails the AUTOVACUM process. > > Thanks > > Danny > -- Adrian Klaver adrian.klaver@gmail.com
Hi, >Are the servers on the Windows versions you mention or the clients or both? Both clients as well as server are located on the same Windows Server machine. >Where is this error showing up, the Windows or Postgres logs? Both. It appears in the pg_log as well as failing the client >What does the other log show? Nothing special. Once logged in PG is fine. >Is there anything preceding the above that might shed light? Unfortunately not. Memory problems within Windows (Error 487) used to be common in 8.3.7 ... but got solved in 8.3.15. We are now having them again with 9.2.4. >Are the connections across a network and if so is there a firewall between the clients and server(s)? No FW involved. All the connections are local. This is a pure , inconsistent Server problem. See BUG #5578: postrgesql database crash .... Thanks Danny
On 01/13/2014 01:44 AM, Abraham, Danny wrote: > Hi, > > >> Are the servers on the Windows versions you mention or the clients or both? > Both clients as well as server are located on the same Windows Server machine. > >> Where is this error showing up, the Windows or Postgres logs? > Both. It appears in the pg_log as well as failing the client > >> What does the other log show? > Nothing special. Once logged in PG is fine. > >> Is there anything preceding the above that might shed light? > Unfortunately not. Memory problems within Windows (Error 487) used to be common in 8.3.7 ... but got solved in 8.3.15. > We are now having them again with 9.2.4. From what I can find WSACancelBlockingCall is a Winsock function has to do with networking/messaging and not memory issues per se. So what makes you think it is a memory issue or are the memory problems a separate issue? See below for more detail on WSACancelBlockingCall, it might help you determine how to debug: http://www.sockets.com/winsock.htm#CancelBlockingCall > >> Are the connections across a network and if so is there a firewall between the clients and server(s)? > No FW involved. All the connections are local. This is a pure , inconsistent Server problem. > See BUG #5578: postrgesql database crash .... Looked at the bug report and the last comment was from Robert Haas who indicated there was not enough information to work with. I would say we are at that same point now. In your first post you mention that this is related to connection attempts. So: What clients are connecting and is it restricted to particular clients? How many connections are you attempting at a time? You said many connection refusals are happening, how many as percent of total? You also mentioned 'Sometimes it even fails the AUTOVACUM process'. What does that mean, the AUTOVACUM process cannot connect, it connects but then fails, other? Also what is the log entry when AUTOVACUM fails? > > > Thanks > > Danny > -- Adrian Klaver adrian.klaver@gmail.com
Hi, Thanks a lot for your reply ... From what I can find WSACancelBlockingCall is a Winsock function has to do with networking/messaging and not memory issuesper se. So what makes you think it is a memory issue >or are the memory problems a separate issue? See below for more detail on WSACancelBlockingCall, it might help you determine how to debug: http://www.sockets.com/winsock.htm#CancelBlockingCall >Looked at the bug report and the last comment was from Robert Haas who indicated there was not enough information to workwith. I would say we are at that same point now. >In your first post you mention that this is related to connection attempts. >So: >What clients are connecting and is it restricted to particular clients? This is in fact a long installation thread that is using JDBC code, some libpq/C, some psql scripts. Not many connections in parallel. Just one thread that is opening and closing a few connections to the PG server. >How many connections are you attempting at a time? Very few of them >You said many connection refusals are happening, how many as percent of total? This is a brand new server, automatically installed. Once initdb is over ... PG will not allow connections. >You also mentioned 'Sometimes it even fails the AUTOVACUM process'. 2014-01-07 15:56:11.232 GMTLOG: autovacuum launcher started 2014-01-07 15:56:23.687 GMTLOG: could not reserve shared memory region (addr=0000000001080000) for child 0000000000001354:error code 487 2014-01-07 15:56:23.687 GMTLOG: could not fork new process for connection: A blocking operation was interrupted by a callto WSACancelBlockingCall. >What does that mean, the AUTOVACUM process cannot connect, it connects but then fails, other? As you see above, it does not connect... >Also what is the log entry when AUTOVACUM fails?
On 01/13/2014 08:43 AM, Abraham, Danny wrote: > Hi, > > Thanks a lot for your reply ... > >From what I can find WSACancelBlockingCall is a Winsock function has to do with networking/messaging and not memory issuesper se. So what makes you think it is a memory issue >or are the memory problems a separate issue? > > > See below for more detail on WSACancelBlockingCall, it might help you determine how to debug: > > http://www.sockets.com/winsock.htm#CancelBlockingCall > >> Looked at the bug report and the last comment was from Robert Haas who indicated there was not enough information to workwith. I would say we are at that same point now. >> In your first post you mention that this is related to connection attempts. >> So: >> What clients are connecting and is it restricted to particular clients? > > This is in fact a long installation thread that is using JDBC code, some libpq/C, some psql scripts. > Not many connections in parallel. Just one thread that is opening and closing a few connections to the PG server. I know I am asking a lot of questions, just trying narrow down the parameters. In all honesty my knowledge of Windows internals is limited but the hope is that sufficient information will trigger an aha moment in others on the list with more experience in this area. So this is just happening when you do the install of the server? So you are using an install of your own making and not using the graphical installer from the download site, or are using it in combination? Of course this leads to, what exactly is the install procedure trying to do? By any chance are trying to load plugin_debugger.dll as in the #5578 bug report? > >> How many connections are you attempting at a time? > Very few of them > >> You said many connection refusals are happening, how many as percent of total? > This is a brand new server, automatically installed. > Once initdb is over ... PG will not allow connections. So how does that reconcile with this from your previous post? "Nothing special. Once logged in PG is fine." > > >> You also mentioned 'Sometimes it even fails the AUTOVACUM process'. > > 2014-01-07 15:56:11.232 GMTLOG: autovacuum launcher started > 2014-01-07 15:56:23.687 GMTLOG: could not reserve shared memory region (addr=0000000001080000) for child 0000000000001354:error code 487 > 2014-01-07 15:56:23.687 GMTLOG: could not fork new process for connection: A blocking operation was interrupted by a callto WSACancelBlockingCall. So is this during the same install process as above or after the server is 'up' and running? -- Adrian Klaver adrian.klaver@gmail.com
Hi, Does anyone know whether this link has an open bug? Maybe a fix? http://www.postgresql.org/message-id/5046CAEB.4010600@grammatech.com Thanks Danny
On 01/14/2014 04:54 AM, Abraham, Danny wrote: > Hi, > > Does anyone know whether this link has an open bug? Maybe a fix? > > http://www.postgresql.org/message-id/5046CAEB.4010600@grammatech.com If it where me I would file a bug report here; http://www.postgresql.org/support/submitbug/ In the report reference Bug #5578, the link above and this thread. > > Thanks > > Danny > -- Adrian Klaver adrian.klaver@gmail.com
On 01/14/2014 04:54 AM, Abraham, Danny wrote: > Hi, > > Does anyone know whether this link has an open bug? Maybe a fix? > > http://www.postgresql.org/message-id/5046CAEB.4010600@grammatech.com In addition to my suggestion to file a bug report, I came with another idea. In a previous post you said: " Memory problems within Windows (Error 487) used to be common in 8.3.7 ... but got solved in 8.3.15." Was that something you just noticed or was the move to 8.3.15 a deliberate act based on some relevant information? If so what was fixed in 8.3.15 that helped with error? It that is known it may help narrow the list of suspects. > > Thanks > > Danny > -- Adrian Klaver adrian.klaver@gmail.com