Skip site navigation (1) Skip section navigation (2)

Re: Unknown winsock error 10061

From: Tsutomu Yamada <tsutomu(at)sraoss(dot)co(dot)jp>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Unknown winsock error 10061
Date: 2009-07-08 13:03:09
Message-ID: 73287.1247058189@srapc2360.sra.co.jp (view raw or flat)
Thread:
Lists: pgsql-bugs
Dave Page <dpage(at)pgadmin(dot)org> wrote:
 > 2009/7/7 Wojciech Strzałka <wstrzalka(at)gmail(dot)com>:
 > >
 > >  Here ( http://www.codelabs.pl/_varia/pg.zip ) is detailed info from
 > >  my machine (PostgreSQL 8.3.6, compiled by Visual C++ build 1400):
 > >
 > >  - detailed log file with several memory attach problems
 > >  - process activity log file (created by Process Monitor from SysInternals)
 > >  - dll's loaded by postgres.exe (snapshot only)
 > >
 > >  Maybe by comparing log entries you will be able to tell smth.
 > 
 > I can't spot anything obviously wrong (other than the original error
 > of course). My only suggestion right now is that we try putting a
 > retry loop in PGSharedMemoryReAttach() and see if the error is a
 > transient thing.
 > 
 > Any other ideas?

Hello,

When failed to reattach, how about the memory regions ?

For instance, do Sleep() when reattach failed, and check the memory by VMMap.
(from SysInternals)
# Of course, it becomes only for debugging.

I think the region to be used as Shared Memory might be used as Heap.
compare with the parent process.

I don't know why the Heap region moves.
 - the order of which DLL is loaded ?
 - Heap size is changed ?

I think this error often occurs when postmater receives a lot of requests.
In our environment, we can reproduce error by following tests.
# AMD Opteron 850 (4 processor) + Windows Server 2008

(Windows server)
postgresql.conf
  max_connections = 300

(*nix client)
export PGHOST=WINDOWS
export PGUSER=postgres
while :; do
  pgbench -n -c 250 || break
done
# maybe fail in 3 to 5 loops


Though the topic changes a little, we are testing about this problem.

In the past, there was the thread about this problem,
and it suggested using VirtualAllocEx().
(But no patch was posted, right?)
http://archives.postgresql.org/pgsql-general/2007-08/msg01592.php

So I tries using VirtualAllocEx().
By this fix, the problem doesn't occur in testing by pgbench.

However, I cannot explain why the memory region was changed,
and cannot guarantee that all problems are solved.

FYI, my patch is put up.
Sorry for large patch, it has too many debug codes.

* postmaster.c
  In internal_forkexec(), reserve shared memory region before ResumeThread().

* win32_shmem.c
  new function to do VirtualAllocEx()
  PGSharedMemoryReAttach() free reserved region before MapViewOfFileEx()

* DEBUG code
  if define DEBUG_VQ, outputs info about memory regions to stderr.
  (Sorry, it is not so useful...)

  if define DEBUG_VQ_DONT_RESERV,
   don't call VirtualAllocEx()/VirtualFree(), so it works as original
   with debug-outs.
   This do Sleep() when reattach fail.


regards,

-- 
Tsutomu Yamada
SRA OSS, Inc. Japan

In response to

Responses

pgsql-bugs by date

Next:From: Joe UhlDate: 2009-07-08 14:15:37
Subject: Nonexistent pid in pg_locks
Previous:From: Wojciech StrzałkaDate: 2009-07-08 12:29:42
Subject: Re: Unknown winsock error 10061

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group