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 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 >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? 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 call to 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? -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
