Thread: Unknown winsock error 10061

Unknown winsock error 10061

From
wstrzalka
Date:
After upgrading to 8.4 on Vista I see no progress on the shared memory
problem unfortunately.

I think it's even worse now (previously it happened mainly when OS
went to sleep & then was restored, now it's all the time).

My log looks like this.

----------------------------------------------------------------------------------------------------------------------------------------------
FATAL:  could not reattach to shared memory (key=288, addr=02A00000):
487
2009-07-06 11:39:45 CESTLOG:  could not receive data from client:
Unknown winsock error 10061
2009-07-06 11:39:45 CESTLOG:  unexpected EOF on client connection
FATAL:  could not reattach to shared memory (key=288, addr=02A00000):
487
2009-07-06 11:40:20 CESTLOG:  could not receive data from client:
Unknown winsock error 10061
2009-07-06 11:40:20 CESTLOG:  unexpected EOF on client connection
2009-07-06 11:40:20 CESTLOG:  could not receive data from client:
Unknown winsock error 10061
2009-07-06 11:40:20 CESTLOG:  unexpected EOF on client connection

-----------------------------------------------------------------------------------------------------------------------------------------------

Our application runs on Linux in the production environment, but all
the developers works on Windows with local PG installations. Some of
them are getting the error - some don't.
.
It's really big problem explaining to the people that PG is really
good database.

Is there any chance to do something with it?

Re: Unknown winsock error 10061

From
Dave Page
Date:
On Mon, Jul 6, 2009 at 11:20 AM, wstrzalka<wstrzalka@gmail.com> wrote:
> After upgrading to 8.4 on Vista I see no progress on the shared memory
> problem unfortunately.
>
> I think it's even worse now (previously it happened mainly when OS
> went to sleep & then was restored, now it's all the time).
>
> My log looks like this.
> -------------------------------------------------------------------------=
---------------------------------------------------------------------
> FATAL: =A0could not reattach to shared memory (key=3D288, addr=3D02A00000=
):
> 487
> 2009-07-06 11:39:45 CESTLOG: =A0could not receive data from client:
> Unknown winsock error 10061
> 2009-07-06 11:39:45 CESTLOG: =A0unexpected EOF on client connection
> FATAL: =A0could not reattach to shared memory (key=3D288, addr=3D02A00000=
):
> 487
> 2009-07-06 11:40:20 CESTLOG: =A0could not receive data from client:
> Unknown winsock error 10061
> 2009-07-06 11:40:20 CESTLOG: =A0unexpected EOF on client connection
> 2009-07-06 11:40:20 CESTLOG: =A0could not receive data from client:
> Unknown winsock error 10061
> 2009-07-06 11:40:20 CESTLOG: =A0unexpected EOF on client connection
> -------------------------------------------------------------------------=
----------------------------------------------------------------------
>
> Our application runs on Linux in the production environment, but all
> the developers works on Windows with local PG installations. Some of
> them are getting the error - some don't.
> .
> It's really big problem explaining to the people that PG is really
> good database.
>
> Is there any chance to do something with it?

We'd love to, but noone with Windows development experience and
familiarity with how PostgreSQL works has yet to be able to reproduce
the problem. As you have a some people that are affected and some that
aren't, perhaps you can help figure out what triggers the bug. Can you
tell if there is any distinguishing factor between the two groups?
Maybe installation options chosen, other software that's installed
(particularly anti-virus or firewall packages), windows service pack
level, domain membership, particular hardware?


--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
No really a pattern.I'm sure PG is installed in standard pure version everywhere.No domains at all.The rest is really
custom(we are working remotely - each of us withdifferent hardware, OS, software, etc...).Maybe the intel dual core has
smthto do about it ? 
Those are affected:
My machine is: Latitude D620, T7200, 3GB RAM, Vista Business SP2, NOD32 3.2, Windows Firewall
Guy 1: Latitude D620, T7200, 2GB RAM, XP Prof SP3, NOD32 3.2, OutpostFirewall
Guy 2: HP T5600 3GB RAM,XP SP2, F-Internet Security 2009Guy 3: Acer (2 core also!!), 4GB RAM, Vista Sp2, Norton
Ativirus

Which is 4 of 8 in the team.
On 8.3 it's usable - the bug is there,but we are using pooling so it retries several times and then keepsthe connection
-the problem is when you try psql ... 
With 8.4 it's almost impossible to connect.


> On Mon, Jul 6, 2009 at 11:20 AM, wstrzalka<wstrzalka@gmail.com> wrote:
>> After upgrading to 8.4 on Vista I see no progress on the shared memory
>> problem unfortunately.
>>
>> I think it's even worse now (previously it happened mainly when OS
>> went to sleep & then was restored, now it's all the time).
>>
>> My log looks like this.
>>
----------------------------------------------------------------------------------------------------------------------------------------------
>> FATAL:  could not reattach to shared memory (key=288, addr=02A00000):
>> 487
>> 2009-07-06 11:39:45 CESTLOG:  could not receive data from client:
>> iso-8859-1 winsock error 10061
>> 2009-07-06 11:39:45 CESTLOG:  unexpected EOF on client connection
>> FATAL:  could not reattach to shared memory (key=288, addr=02A00000):
>> 487
>> 2009-07-06 11:40:20 CESTLOG:  could not receive data from client:
>> iso-8859-1 winsock error 10061
>> 2009-07-06 11:40:20 CESTLOG:  unexpected EOF on client connection
>> 2009-07-06 11:40:20 CESTLOG:  could not receive data from client:
>> iso-8859-1 winsock error 10061
>> 2009-07-06 11:40:20 CESTLOG:  unexpected EOF on client connection
>>
-----------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Our application runs on Linux in the production environment, but all
>> the developers works on Windows with local PG installations. Some of
>> them are getting the error - some don't.
>> .
>> It's really big problem explaining to the people that PG is really
>> good database.
>>
>> Is there any chance to do something with it?

> We'd love to, but noone with Windows development experience and
> familiarity with how PostgreSQL works has yet to be able to reproduce
> the problem. As you have a some people that are affected and some that
> aren't, perhaps you can help figure out what triggers the bug. Can you
> tell if there is any distinguishing factor between the two groups?
> Maybe installation options chosen, other software that's installed
> (particularly anti-virus or firewall packages), windows service pack
> level, domain membership, particular hardware?





--
Pozdrowienia,Wojciech Strzalka



Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
All of the machines are laptops. Maybe some power management stuff ?

> On Mon, Jul 6, 2009 at 11:20 AM, wstrzalka<wstrzalka@gmail.com> wrote:
>> After upgrading to 8.4 on Vista I see no progress on the shared memory
>> problem unfortunately.
>>
>> I think it's even worse now (previously it happened mainly when OS
>> went to sleep & then was restored, now it's all the time).
>>
>> My log looks like this.
>>
----------------------------------------------------------------------------------------------------------------------------------------------
>> FATAL:  could not reattach to shared memory (key=288, addr=02A00000):
>> 487
>> 2009-07-06 11:39:45 CESTLOG:  could not receive data from client:
>> iso-8859-1 winsock error 10061
>> 2009-07-06 11:39:45 CESTLOG:  unexpected EOF on client connection
>> FATAL:  could not reattach to shared memory (key=288, addr=02A00000):
>> 487
>> 2009-07-06 11:40:20 CESTLOG:  could not receive data from client:
>> iso-8859-1 winsock error 10061
>> 2009-07-06 11:40:20 CESTLOG:  unexpected EOF on client connection
>> 2009-07-06 11:40:20 CESTLOG:  could not receive data from client:
>> iso-8859-1 winsock error 10061
>> 2009-07-06 11:40:20 CESTLOG:  unexpected EOF on client connection
>>
-----------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Our application runs on Linux in the production environment, but all
>> the developers works on Windows with local PG installations. Some of
>> them are getting the error - some don't.
>> .
>> It's really big problem explaining to the people that PG is really
>> good database.
>>
>> Is there any chance to do something with it?

> We'd love to, but noone with Windows development experience and
> familiarity with how PostgreSQL works has yet to be able to reproduce
> the problem. As you have a some people that are affected and some that
> aren't, perhaps you can help figure out what triggers the bug. Can you
> tell if there is any distinguishing factor between the two groups?
> Maybe installation options chosen, other software that's installed
> (particularly anti-virus or firewall packages), windows service pack
> level, domain membership, particular hardware?





--
Pozdrowienia,Wojciech Strzalka



Re: Unknown winsock error 10061

From
Dave Page
Date:
2009/7/6 Wojciech Strza=C5=82ka <wstrzalka@gmail.com>:
>
> =C2=A0No really a pattern.
> =C2=A0I'm sure PG is installed in standard pure version everywhere.
> =C2=A0No domains at all.
> =C2=A0The rest is really custom (we are working remotely - each of us with
> =C2=A0different hardware, OS, software, etc...).
> =C2=A0Maybe the intel dual core has smth to do about it ?

I run a core 2 duo and have never seen any problems. I don't exactly
hammer the server though.

> =C2=A0Those are affected:
>
> =C2=A0My machine is:
> =C2=A0Latitude D620, T7200, 3GB RAM, Vista Business SP2, NOD32 3.2, Windo=
ws Firewall
>
> =C2=A0Guy 1:
> =C2=A0Latitude D620, T7200, 2GB RAM, XP Prof SP3, NOD32 3.2, OutpostFirew=
all
>
> =C2=A0Guy 2:
> =C2=A0HP T5600 3GB RAM,XP SP2, F-Internet Security 2009
>
> =C2=A0Guy 3: Acer (2 core also!!), 4GB RAM, Vista Sp2, Norton Ativirus
>
>
> =C2=A0Which is 4 of 8 in the team.

What about those that don't see the problem? I'll grant you those 4
are pretty different though.



--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Rainer Bauer
Date:
Wojciech Strza?ka wrote:

> All of the machines are laptops. Maybe some power management stuff ?

I experienced problems with the Standby mode (that was with pg8.2 and XPSP2).
But since this is a workstation I just stopped using the Standby mode.

I never looked into the log files but what happened was that the CPU went up
100% and the complete system was unresponsive when it was woken up (the
Taskmanager showed that a Postgres process was using the CPU). I had to reboot
the machine every time this happened. This was not reproducable (in fact it
happened maybe one in 10 times).

I never investigated this, because I thought that Postgres was not supposed to
support the Standby mode, since a database server normally runs 24 hour a day.

Rainer

Re: Unknown winsock error 10061

From
wstrzalka
Date:
In my case standby mode only increases the frequency - problem occurs
also on clean machine - right after startup.
 8.4 is totally unusable on my vista. I had to downgrade back to 8.3

 I've just uninstalled antivirus & disabled windows firewall - no
effect.
The strange is that subsequent requests does not behave the same -
some are succesfull, some don't.

I'll set debug level to max - maybe there will be something
interesting.


On 6 Lip, 15:47, Rainer Bauer <use...@munnin.com> wrote:
> Wojciech Strza?ka wrote:
> > All of the machines are laptops. Maybe some power management stuff ?
>
> I experienced problems with the Standby mode (that was with pg8.2 and XPSP2).
> But since this is a workstation I just stopped using the Standby mode.
>
> I never looked into the log files but what happened was that the CPU went up
> 100% and the complete system was unresponsive when it was woken up (the
> Taskmanager showed that a Postgres process was using the CPU). I had to reboot
> the machine every time this happened. This was not reproducable (in fact it
> happened maybe one in 10 times).
>
> I never investigated this, because I thought that Postgres was not supposed to
> support the Standby mode, since a database server normally runs 24 hour a day.
>
> Rainer

Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
I don't suppose this explains anything but - why not to try (this is
DEBUG and has more details, but looks like some information are less detailed than in
INFO log level ?? (ie. socket error code is missing):

2009-07-06 23:31:12 CEST DEBUG:  00000: shmem_exit(0)
2009-07-06 23:31:12 CEST LOCATION:  shmem_exit, .\src\backend\storage\ipc\ipc.c:164
2009-07-06 23:31:12 CEST DEBUG:  00000: exit(0)
2009-07-06 23:31:12 CEST LOCATION:  proc_exit, .\src\backend\storage\ipc\ipc.c:116
2009-07-06 23:31:12 CEST DEBUG:  00000: forked new backend, pid=1468 socket=944
2009-07-06 23:31:12 CEST LOCATION:  BackendStartup, .\src\backend\postmaster\postmaster.c:2850
2009-07-06 23:31:12 CEST DEBUG:  00000: reaping dead processes
2009-07-06 23:31:12 CEST LOCATION:  reaper, .\src\backend\postmaster\postmaster.c:2082
2009-07-06 23:31:12 CEST DEBUG:  00000: server process (PID 3096) exited with exit code 0
2009-07-06 23:31:12 CEST LOCATION:  LogChildExit, .\src\backend\postmaster\postmaster.c:2509
2009-07-06 23:31:12 CEST DEBUG:  00000: forked new backend, pid=7868 socket=908
2009-07-06 23:31:12 CEST LOCATION:  BackendStartup, .\src\backend\postmaster\postmaster.c:2850
FATAL:  could not reattach to shared memory (key=248, addr=02100000): 487
2009-07-06 23:31:12 CEST LOG:  00000: loaded library "$libdir/plugins/plugin_debugger.dll"
2009-07-06 23:31:12 CEST LOCATION:  load_libraries, .\src\backend\utils\init\miscinit.c:1187
2009-07-06 23:31:12 CEST DEBUG:  00000: postgres child[7868]: starting with (
2009-07-06 23:31:12 CEST LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3198
2009-07-06 23:31:12 CEST DEBUG:  00000:         postgres
2009-07-06 23:31:12 CEST LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3201
2009-07-06 23:31:12 CEST DEBUG:  00000:         -v196608
2009-07-06 23:31:12 CEST LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3201
2009-07-06 23:31:12 CEST DEBUG:  00000:         -y
2009-07-06 23:31:12 CEST LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3201
2009-07-06 23:31:12 CEST DEBUG:  00000:         onebigdb
2009-07-06 23:31:12 CEST LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3201
2009-07-06 23:31:12 CEST DEBUG:  00000: )
2009-07-06 23:31:12 CEST LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3203
2009-07-06 23:31:12 CEST DEBUG:  00000: InitPostgres
2009-07-06 23:31:12 CEST LOCATION:  PostgresMain, .\src\backend\tcop\postgres.c:3347
2009-07-06 23:31:12 CEST DEBUG:  00000: reaping dead processes
2009-07-06 23:31:12 CEST LOCATION:  reaper, .\src\backend\postmaster\postmaster.c:2082
2009-07-06 23:31:12 CEST DEBUG:  00000: server process (PID 1468) exited with exit code 1
2009-07-06 23:31:12 CEST LOCATION:  LogChildExit, .\src\backend\postmaster\postmaster.c:2509
2009-07-06 23:31:12 CEST DEBUG:  00000: StartTransaction

Is there any way I could help with problem investigation?

Maybe some prepared version with extra debug.

Setting up build env. looks quite crazy but I could try
with some help (this will take quite long time assuming my free time,
but if there is no other way ...).



> 2009/7/6 Wojciech Strzałka <wstrzalka@gmail.com>:
>>
>>  No really a pattern.
>>  I'm sure PG is installed in standard pure version everywhere.
>>  No domains at all.
>>  The rest is really custom (we are working remotely - each of us with
>>  different hardware, OS, software, etc...).
>>  Maybe the intel dual core has smth to do about it ?

> I run a core 2 duo and have never seen any problems. I don't exactly
> hammer the server though.

>>  Those are affected:
>>
>>  My machine is:
>>  Latitude D620, T7200, 3GB RAM, Vista Business SP2, NOD32 3.2, Windows Firewall
>>
>>  Guy 1:
>>  Latitude D620, T7200, 2GB RAM, XP Prof SP3, NOD32 3.2, OutpostFirewall
>>
>>  Guy 2:
>>  HP T5600 3GB RAM,XP SP2, F-Internet Security 2009
>>
>>  Guy 3: Acer (2 core also!!), 4GB RAM, Vista Sp2, Norton Ativirus
>>
>>
>>  Which is 4 of 8 in the team.

> What about those that don't see the problem? I'll grant you those 4
> are pretty different though.






--
Pozdrowienia,Wojciech Strzałka



Re: Unknown winsock error 10061

From
Alvaro Herrera
Date:
Wojciech Strzałka escribió:
>
> I don't suppose this explains anything but - why not to try (this is
> DEBUG and has more details, but looks like some information are less detailed than in
> INFO log level ?? (ie. socket error code is missing):

I suggest you add %p to log_line_prefix to differentiate log lines for
various processes.  Also perhaps you want to set log_error_verbosity to
VERBOSE to see more details about each message.

Since it has been suggested that the problem may be caused by DLLs
loaded or not by the processes, I suggest you try to find out which ones
are attached to each process, when it works and when it doesn't.  Is
there a difference?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: Unknown winsock error 10061

From
Dave Page
Date:
2009/7/6 Alvaro Herrera <alvherre@commandprompt.com>:
> Wojciech Strza=C5=82ka escribi=C3=B3:
>>
>> I don't suppose this explains anything but - why not to try (this is
>> DEBUG and has more details, but looks like some information are less det=
ailed than in
>> INFO log level ?? (ie. socket error code is missing):
>
> I suggest you add %p to log_line_prefix to differentiate log lines for
> various processes. =C2=A0Also perhaps you want to set log_error_verbosity=
 to
> VERBOSE to see more details about each message.
>
> Since it has been suggested that the problem may be caused by DLLs
> loaded or not by the processes, I suggest you try to find out which ones
> are attached to each process, when it works and when it doesn't. =C2=A0Is
> there a difference?

Also, try removing the plugin_debugger.dll from
shared_preload_libraries in postgresql.conf to eliminate that from the
equation.


--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
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.
 Still there is not much info in the pg log file (my config file in package).
 Removing plugin_debugger.dll didn't helped.
> 2009/7/6 Alvaro Herrera <alvherre@commandprompt.com>:
>> Wojciech Strzałka escribió:
>>>
>>> I don't suppose this explains anything but - why not to try (this is
>>> DEBUG and has more details, but looks like some information are less detailed than in
>>> INFO log level ?? (ie. socket error code is missing):
>>
>> I suggest you add %p to log_line_prefix to differentiate log lines for
>> various processes.  Also perhaps you want to set log_error_verbosity to
>> VERBOSE to see more details about each message.
>>
>> Since it has been suggested that the problem may be caused by DLLs
>> loaded or not by the processes, I suggest you try to find out which ones
>> are attached to each process, when it works and when it doesn't.  Is
>> there a difference?

> Also, try removing the plugin_debugger.dll from
> shared_preload_libraries in postgresql.conf to eliminate that from the
> equation.





--
Pozdrowienia,Wojciech Strzałka



Re: Unknown winsock error 10061

From
Dave Page
Date:
2009/7/7 Wojciech Strza=C5=82ka <wstrzalka@gmail.com>:
>
> =C2=A0Here ( http://www.codelabs.pl/_varia/pg.zip ) is detailed info from
> =C2=A0my machine (PostgreSQL 8.3.6, compiled by Visual C++ build 1400):
>
> =C2=A0- detailed log file with several memory attach problems
> =C2=A0- process activity log file (created by Process Monitor from SysInt=
ernals)
> =C2=A0- dll's loaded by postgres.exe (snapshot only)
>
> =C2=A0Maybe 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?

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
Sorry if what i'm talking is completely silly, but  the error code (ERROR_INVALID_ADDRESS - 487 (0x1E7)) returned
from MapViewOfFileEx suggest the ShMem address is wrong. The Windows  error codes are usually not really helpfull but
canwe log the UsedShmemSegAddr and UsedShmemSegID in  PGSharedMemoryCreate and maybe also on successful
PGSharedMemoryReAttach in DEBUG log level?     

> 2009/7/7 Wojciech Strzałka <wstrzalka@gmail.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?




--
Pozdrowienia,Wojciech Strzałka



Re: Unknown winsock error 10061

From
Dave Page
Date:
2009/7/7 Wojciech Strza=C5=82ka <wstrzalka@gmail.com>:
>
> =C2=A0 Sorry if what i'm talking is completely silly, but
> =C2=A0 the error code (ERROR_INVALID_ADDRESS - 487 (0x1E7)) returned from
> =C2=A0 MapViewOfFileEx suggest the ShMem address is wrong. The Windows
> =C2=A0 error codes are usually not really helpfull but
> =C2=A0 can we log the UsedShmemSegAddr and UsedShmemSegID in
> =C2=A0 PGSharedMemoryCreate and maybe also on successful PGSharedMemoryRe=
Attach
> =C2=A0 in DEBUG log level?

We could, but I don't see how it could be wrong, as it's only set in
PGSharedMemoryCreate and when we pass it down from postmaster to
backend. If something we're being stomped on there, I'd expect it to
be a more random problem.

<reads code some more>

Although, the reattach does get called almost immediately following
the backend variables being read, so maybe they are getting clobbered,
and it's pretty much always shows up in the re-mapping of the shared
memory.

What distribution are you running? I'll see if I can hack up a build
with the extra debugging, but I need to get the integer_datetimes
option right for your database.

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime is 'off' at least in 8.3 which is active at the
time).
 Don't hesitate too much - reinstalling binaries with dump & restore of data is not a problem whatever version you'll
sendto me. 

> 2009/7/7 Wojciech Strzałka <wstrzalka@gmail.com>:
>>
>>   Sorry if what i'm talking is completely silly, but
>>   the error code (ERROR_INVALID_ADDRESS - 487 (0x1E7)) returned from
>>   MapViewOfFileEx suggest the ShMem address is wrong. The Windows
>>   error codes are usually not really helpfull but
>>   can we log the UsedShmemSegAddr and UsedShmemSegID in
>>   PGSharedMemoryCreate and maybe also on successful PGSharedMemoryReAttach
>>   in DEBUG log level?

> We could, but I don't see how it could be wrong, as it's only set in
> PGSharedMemoryCreate and when we pass it down from postmaster to
> backend. If something we're being stomped on there, I'd expect it to
> be a more random problem.

> <reads code some more>

> Although, the reattach does get called almost immediately following
> the backend variables being read, so maybe they are getting clobbered,
> and it's pretty much always shows up in the re-mapping of the shared
> memory.

> What distribution are you running? I'll see if I can hack up a build
> with the extra debugging, but I need to get the integer_datetimes
> option right for your database.




--
Pozdrowienia,Wojciech Strzałka



Re: Unknown winsock error 10061

From
Dave Page
Date:
2009/7/7 Wojciech Strza=C5=82ka <wstrzalka@gmail.com>:
>
> =C2=A0I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime
> =C2=A0is 'off' at least in 8.3 which is active at the time).

OK, I put a zip of a server build at
http://uploads.enterprisedb.com/download.php?file=3Dfc168613430d6c1bf756036=
466963a5f

It's PG84, and includes some DEBUG2's in PGSharedMemoryCreate,
PGSharedMemoryReAttach and restore_backend_variables, all prefixed
with ***

It should work with the dependencies that come with the 8.4 installer
- it'll probably be easiest to just drop in postgres.exe to an
existing installation.

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
Witam!

W liście datowanym 7 lipca 2009 (18:02:30) napisano:

> 2009/7/7 Wojciech Strzałka <wstrzalka@gmail.com>:
>>
>>  I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime
>>  is 'off' at least in 8.3 which is active at the time).

> OK, I put a zip of a server build at
> http://uploads.enterprisedb.com/download.php?file=fc168613430d6c1bf756036466963a5f
I was wondering why I can not see the DEBUG2 info you were talkingabout (tripple star), and probably that's another
bug.Whicheverdebug1 - debug5 level I set in config file the pg_settingstells me that it's set to 'debug' (without a
number)- and there isno info you mentioned in config file. 
I can set log level to 'debug5' (as well as back to 'debug' using SET but it's only to current session.
The more strange is that 'debug' is not officialy supported value bythis param. Probably it's some legacy setting
hangingthere and log parser applies itbefore whole word is read (if it makes sense)?What do you say about it? Please
changethe triple star to eg. INFOlevel or take a look at logging level to be able to go forward withthe original
problem.
----------------------------------------------
postgres=# set log_min_error_statement = 'debug';               <--- this is strange
SET
postgres=# set log_min_error_statement = 'debug1';
SET
postgres=# set log_min_error_statement = 'debug6';
ERROR:  invalid value for parameter "log_min_error_statement": "debug6"
-------------------------------------------------

> It's PG84, and includes some DEBUG2's in PGSharedMemoryCreate,
> PGSharedMemoryReAttach and restore_backend_variables, all prefixed
> with ***

> It should work with the dependencies that come with the 8.4 installer
> - it'll probably be easiest to just drop in postgres.exe to an
> existing installation.




--
Pozdrowienia,Wojciech Strzałka



Re: Unknown winsock error 10061

From
Dave Page
Date:
2009/7/8 Wojciech Strza=C5=82ka <wstrzalka@gmail.com>:

> =C2=A0I was wondering why I can not see the DEBUG2 info you were talking
> =C2=A0about (tripple star), and probably that's another bug.
> =C2=A0Whichever debug1 - debug5 level I set in config file the pg_settings
> =C2=A0tells me that it's set to 'debug' (without a number) - and there is
> =C2=A0no info you mentioned in config file.

Yeah, I'm not sure what blackhole that's going down.

> =C2=A0What do you say about it? Please change the triple star to eg. INFO
> =C2=A0level or take a look at logging level to be able to go forward with
> =C2=A0the original problem.

The stars are just text in the message. I tried using elog(INFO...)
but that didn't work either. Not sure why, and I don't really have
time to figure that out. fprintf(stderr...) does work for me however,
please try this:
http://uploads.enterprisedb.com/download.php?file=3De91d1a36ea6e32bc7a867fd=
27d70e597

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
Witam!

W liście datowanym 8 lipca 2009 (13:55:00) napisano:

> 2009/7/8 Wojciech Strzałka <wstrzalka@gmail.com>:

>>  I was wondering why I can not see the DEBUG2 info you were talking
>>  about (tripple star), and probably that's another bug.
>>  Whichever debug1 - debug5 level I set in config file the pg_settings
>>  tells me that it's set to 'debug' (without a number) - and there is
>>  no info you mentioned in config file.

> Yeah, I'm not sure what blackhole that's going down.

Looks like not only MySQL has blackhole storage engine ;)





Re: Unknown winsock error 10061

From
Wojciech Strzałka
Date:
And the result is:

2009-07-08 14:26:00 CEST PID:9612 DEBUG:  00000: forked new backend, pid=8120 socket=948
2009-07-08 14:26:00 CEST PID:9612 LOCATION:  BackendStartup, .\src\backend\postmaster\postmaster.c:3029
*** Finished restoring shared memory vars in restore_backend_variables (key=256, addr=02400000)
FATAL:  could not reattach to shared memory (key=256, addr=02400000): 487
2009-07-08 14:26:00 CEST PID:9612 DEBUG:  00000: reaping dead processes
2009-07-08 14:26:00 CEST PID:9612 LOCATION:  reaper, .\src\backend\postmaster\postmaster.c:2184
2009-07-08 14:26:00 CEST PID:9612 DEBUG:  00000: server process (PID 8120) exited with exit code 1
2009-07-08 14:26:00 CEST PID:9612 LOCATION:  LogChildExit, .\src\backend\postmaster\postmaster.c:2653
2009-07-08 14:26:01 CEST PID:9612 DEBUG:  00000: forked new backend, pid=9952 socket=948
2009-07-08 14:26:01 CEST PID:9612 LOCATION:  BackendStartup, .\src\backend\postmaster\postmaster.c:3029
*** Finished restoring shared memory vars in restore_backend_variables (key=256, addr=02400000)
*** Finished reattaching shared memory segment in PGSharedMemoryReAttach (key=256, addr=02400000)
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: postgres child[9952]: starting with (
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3384
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000:        postgres
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3387
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000:        -v196608
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3387
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000:        -y
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3387
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000:        masterdb
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3387
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: )
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  BackendRun, .\src\backend\postmaster\postmaster.c:3389
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: InitPostgres
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  PostgresMain, .\src\backend\tcop\postgres.c:3333
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: my backend id is 5
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  SharedInvalBackendInit, .\src\backend\storage\ipc\sinvaladt.c:316
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: StartTransaction
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  ShowTransactionState, .\src\backend\access\transam\xact.c:4073
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: name: unnamed; blockState:       DEFAULT; state: INPROGR,
xid/subid/cid:0/1/0, nestlvl: 1, children:  
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  ShowTransactionStateRec, .\src\backend\access\transam\xact.c:4111
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: CommitTransaction
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  ShowTransactionState, .\src\backend\access\transam\xact.c:4073
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: name: unnamed; blockState:       STARTED; state: INPROGR,
xid/subid/cid:0/1/0, nestlvl: 1, children:  
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  ShowTransactionStateRec, .\src\backend\access\transam\xact.c:4111
2009-07-08 14:26:01 CEST PID:9952 DEBUG:  00000: parse <unnamed>: SHOW TRANSACTION ISOLATION LEVEL
2009-07-08 14:26:01 CEST PID:9952 LOCATION:  exec_parse_message, .\src\backend\tcop\postgres.c:1117
2009-07-08 14:26:01 CEST PID:9952 STATEMENT:  SHOW TRANSACTION ISOLATION LEVEL



--
Pozdrowienia,Wojciech Strzałka



Re: Unknown winsock error 10061

From
Tsutomu Yamada
Date:
Dave Page <dpage@pgadmin.org> wrote:
 > 2009/7/7 Wojciech Strzałka <wstrzalka@gmail.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

Index: src/backend/port/win32_shmem.c
===================================================================
RCS file: /mnt/prj/pg/cvsmirror/pg/pgsql/src/backend/port/win32_shmem.c,v
retrieving revision 1.11
diff -c -r1.11 win32_shmem.c
*** src/backend/port/win32_shmem.c    11 Jun 2009 14:49:00 -0000    1.11
--- src/backend/port/win32_shmem.c    8 Jul 2009 11:52:14 -0000
***************
*** 18,23 ****
--- 18,30 ----

  unsigned long UsedShmemSegID = 0;
  void       *UsedShmemSegAddr = NULL;
+ static Size UsedShmemSegSize = 0;
+
+ //#define DEBUG_VQ
+ #ifdef DEBUG_VQ
+ //#define DEBUG_VQ_DONT_RESERV
+ void DumpVirtualQuery(HANDLE);
+ #endif

  static void pgwin32_SharedMemoryDelete(int status, Datum shmId);

***************
*** 183,188 ****
--- 190,200 ----
                  (errmsg("pre-existing shared memory block is still in use"),
                   errhint("Check if there are any old server processes still running, and terminate them.")));

+ #ifdef DEBUG_VQ
+     fprintf(stderr, "before MapViewOfFileEx: hmap=%p (size=%lu, name=%s)\n",
+             hmap, (unsigned long) size, szShareMem);
+     DumpVirtualQuery(NULL);
+ #endif
      free(szShareMem);

      /*
***************
*** 233,240 ****
--- 245,258 ----

      /* Save info for possible future use */
      UsedShmemSegAddr = memAddress;
+     UsedShmemSegSize = size;
      UsedShmemSegID = (unsigned long) hmap2;

+ #ifdef DEBUG_VQ
+     fprintf(stderr, "PGSharedMemoryCreate ok: key %ld, SegAddr=%p\n",
+             UsedShmemSegID, UsedShmemSegAddr);
+     DumpVirtualQuery(NULL);
+ #endif
      return hdr;
  }

***************
*** 257,266 ****
--- 275,361 ----
      Assert(UsedShmemSegAddr != NULL);
      Assert(IsUnderPostmaster);

+ #ifndef DEBUG_VQ_DONT_RESERV
+     {
+         /* release region of memory
+          * reserved by parant process
+          */
+ #ifdef DEBUG_VQ_XXX /* too verbose */
+         fprintf(stderr, "--reattach: before vfree\n");
+         DumpVirtualQuery(NULL);
+ #endif
+         if (VirtualFree(UsedShmemSegAddr, UsedShmemSegSize, MEM_RELEASE) == 0)
+         {
+ #ifndef DEBUG_VQ
+             elog(WARNING, "failed to release pre-reserved memory: %lu",
+                  GetLastError());
+ #else /* verbose errer message */
+             LPVOID lpMsgBuf;
+             unsigned long ecode;
+             FormatMessage(
+                 FORMAT_MESSAGE_ALLOCATE_BUFFER |
+                 FORMAT_MESSAGE_FROM_SYSTEM |
+                 FORMAT_MESSAGE_IGNORE_INSERTS,
+                 NULL,
+                 ecode = GetLastError(),
+                 MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), //
+                 (LPTSTR) &lpMsgBuf,
+                 0,
+                 NULL
+                 );
+             fprintf(stderr, "== VirtualFree fail: %lu: %s\n", ecode, lpMsgBuf);
+             LocalFree(lpMsgBuf);
+ #endif
+         }
+ #ifdef DEBUG_VQ_XXX /* too verbose */
+         fprintf(stderr, "--reattach: after vfree\n");
+         DumpVirtualQuery(NULL);
+ #endif
+     }
+ #endif
+
      hdr = (PGShmemHeader *) MapViewOfFileEx((HANDLE) UsedShmemSegID, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0,
UsedShmemSegAddr);
      if (!hdr)
+ #ifndef DEBUG_VQ
          elog(FATAL, "could not reattach to shared memory (key=%d, addr=%p): %lu",
               (int) UsedShmemSegID, UsedShmemSegAddr, GetLastError());
+ #else
+     {
+         LPVOID lpMsgBuf;
+         unsigned long ecode;
+         FormatMessage(
+             FORMAT_MESSAGE_ALLOCATE_BUFFER |
+             FORMAT_MESSAGE_FROM_SYSTEM |
+             FORMAT_MESSAGE_IGNORE_INSERTS,
+             NULL,
+             ecode = GetLastError(),
+             MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), //
+             (LPTSTR) &lpMsgBuf,
+             0,
+             NULL
+             );
+         fprintf(stderr, "ReAttach fail: PID=%d, hdr(new)%p, Used %p\n",
+                 getpid(), hdr, UsedShmemSegAddr);
+         DumpVirtualQuery(NULL);
+ #ifdef DEBUG_VQ_DONT_RESERV
+         {
+             /* XXX: to use monitor utilities */
+             int ii;
+             for (ii = 0; ii < 10; ii++) {
+                 fprintf(stderr, "--sleeping: reattach fail: PID=%d SegAddr=%p\n", getpid(), UsedShmemSegAddr);
+                 Sleep(1000 * 60);
+             }
+         }
+ #endif
+         elog(FATAL, "could not reattach to shared memory (key=%d, addr=%p): %lu: %s",
+              (int) UsedShmemSegID, UsedShmemSegAddr, ecode, lpMsgBuf);
+         LocalFree(lpMsgBuf);
+     }
+ #endif
+ #ifdef DEBUG_VQ_XXX /* too verbose */
+     fprintf(stderr, "--reattach: after mapview\n");
+     DumpVirtualQuery(NULL);
+ #endif
      if (hdr != origUsedShmemSegAddr)
          elog(FATAL, "reattaching to shared memory returned unexpected address (got %p, expected %p)",
               hdr, origUsedShmemSegAddr);
***************
*** 302,304 ****
--- 397,621 ----
      if (!CloseHandle((HANDLE) DatumGetInt32(shmId)))
          elog(LOG, "could not close handle to shared memory: %lu", GetLastError());
  }
+
+ /*
+  * pgwin32_ReserveSharedMemory(HANDLE pChild)
+  * Reserve shared memory area,
+  * BEFORE child process allocates memory for DLL and/or others.
+  */
+ void
+ pgwin32_ReserveSharedMemory(HANDLE pChild)
+ {
+     void *memAddress;
+
+ #ifdef DEBUG_VQ
+     static int debugcnt = 10;
+     int do_dumpVQ = 0;
+
+ #ifdef DEBUG_VQ_DONT_RESERV
+     return; /* do nothing */
+ #endif
+
+     /* dump Nth child */
+     if (debugcnt > 0) {
+         if (--debugcnt == 0) {
+             do_dumpVQ = 1;
+         }
+     }
+
+     if (do_dumpVQ) {
+         fprintf(stderr, "== before VirtualAllocEx %p: SegAddr=%p size=%lu\n",
+                 pChild, UsedShmemSegAddr, (unsigned long) UsedShmemSegSize);
+         DumpVirtualQuery(pChild);
+     }
+ #endif
+
+     Assert(UsedShmemSegAddr != NULL);
+     memAddress = VirtualAllocEx(pChild, UsedShmemSegAddr, UsedShmemSegSize,
+                                 MEM_RESERVE, PAGE_READWRITE);
+     if (memAddress == NULL) {
+ #ifndef DEBUG_VQ
+         elog(LOG, "could not reserve shared memory area: error code %lu",
+              GetLastError());
+ #else
+         LPVOID lpMsgBuf;
+         unsigned long ecode;
+         FormatMessage(
+             FORMAT_MESSAGE_ALLOCATE_BUFFER |
+             FORMAT_MESSAGE_FROM_SYSTEM |
+             FORMAT_MESSAGE_IGNORE_INSERTS,
+             NULL,
+             ecode = GetLastError(),
+             MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), //
+             (LPTSTR) &lpMsgBuf,
+             0,
+             NULL
+             );
+         fprintf(stderr, "== VirtualAllocEx fail: %lu: %s\n", ecode, lpMsgBuf);
+         LocalFree(lpMsgBuf);
+ #endif
+     }
+
+ #ifdef DEBUG_VQ
+     if (do_dumpVQ) {
+         fprintf(stderr, "== after VirtualAllocEx: mem=%p\n", memAddress);
+         DumpVirtualQuery(pChild);
+     }
+ #endif
+ }
+
+ #ifdef DEBUG_VQ
+ /* debug
+  */
+ struct flg2str {
+     DWORD flg;
+     char *str;
+ };
+
+ /* XXX: all strings has same width */
+ static struct flg2str protection[] = {
+     { PAGE_EXECUTE,                "EXEC " },
+     { PAGE_EXECUTE_READ,        "EX_RO" },
+     { PAGE_EXECUTE_READWRITE,    "EX_RW" },
+     { PAGE_EXECUTE_WRITECOPY,    "EX_WC" },
+     { PAGE_NOACCESS,            "NOACC" },
+     { PAGE_READONLY,            "RONLY" },
+     { PAGE_READWRITE,            "RW   " },
+     { PAGE_WRITECOPY,            "WCOPY" },
+     { 0, NULL }
+ };
+
+ static struct flg2str p_modifiers[] = {
+     { PAGE_GUARD, "-PG" },
+     { PAGE_NOCACHE, "-NC" },
+     { PAGE_WRITECOMBINE, "-WC" },
+     { 0, NULL }
+ };
+
+ static struct flg2str page_state[] = {
+     { MEM_COMMIT,    "commit " },
+     { MEM_FREE,        "free   " },
+     { MEM_RESERVE,    "reserve" },
+     { 0, NULL }
+ };
+
+ static struct flg2str page_type[] = {
+     { MEM_IMAGE,    "image  " },
+     { MEM_MAPPED,    "mapped " },
+     { MEM_PRIVATE,    "private" },
+     { 0, NULL }
+ };
+
+ static void print_flg(struct flg2str f2s[], DWORD flgval)
+ {
+     int i;
+
+     for (i = 0; f2s[i].str != NULL; i++) {
+         if (f2s[i].flg == flgval) {
+             fprintf(stderr, " %s", f2s[i].str);
+             break;
+         }
+     }
+     if (f2s[i].str == NULL) {
+         fprintf(stderr, " ?%x", flgval);
+     }
+     return;
+ }
+
+ static void DumpVirtualQuery(HANDLE hProcess)
+ {
+     SIZE_T length;
+     LPCBYTE addr;
+     LPCBYTE prevBase = NULL;
+     MEMORY_BASIC_INFORMATION infobuff;
+     SIZE_T dwLength = sizeof(infobuff);
+     int i = 0;
+
+     fprintf(stderr, "-VQ- %p\n", hProcess);
+     addr = NULL;
+
+     for (;;) {
+         if (hProcess != NULL)
+             length = VirtualQueryEx(hProcess, addr, &infobuff, dwLength);
+         else
+             length = VirtualQuery(addr, &infobuff, dwLength);
+
+         if (length <= 0)
+             break;
+
+         if (length != dwLength) {
+             fprintf(stderr, "?VQ fail?");
+         }
+
+ #ifdef _WIN64
+ #define PADDR(x) fprintf(stderr, "%011llX", (unsigned long long) (x))
+ #define PSAME()  fprintf(stderr, " |         ")
+ #else
+ #define PADDR(x) fprintf(stderr, "%p", (x))
+ #define PSAME()  fprintf(stderr, " |      ")
+ #endif
+
+         /* addr, size */
+         PADDR(infobuff.BaseAddress);
+         fprintf(stderr, "-");
+         PADDR((LPCBYTE) infobuff.BaseAddress + infobuff.RegionSize - 1);
+         fprintf(stderr, " ");
+
+         if (infobuff.AllocationBase == NULL) {
+             /* not mapped */
+             fprintf(stderr, "-nomap-");
+             /* assert */
+             if (infobuff.AllocationProtect != 0 ||
+                 infobuff.State != MEM_FREE ||
+                 infobuff.Protect != PAGE_NOACCESS ||
+                 !(infobuff.Type == 0 || infobuff.Type == MEM_IMAGE)) {
+                 fprintf(stderr, " ??? ap=%x, s=%x, p=%x, t=%x",
+                         infobuff.AllocationProtect,
+                         infobuff.State,
+                         infobuff.Protect,
+                         infobuff.Type);
+             }
+         } else {
+             if ((LPCBYTE) infobuff.AllocationBase == prevBase) {
+                 /* same allocation base as above */
+                 PSAME();
+             } else {
+                 prevBase = (LPCBYTE) infobuff.AllocationBase;
+                 PADDR(infobuff.AllocationBase);
+             }
+
+             /* flags */
+             print_flg(protection, (infobuff.AllocationProtect & 0xff));
+             if (infobuff.AllocationProtect & ~0xff) {
+                 print_flg(p_modifiers, (infobuff.AllocationProtect & ~0xff));
+             }
+
+             print_flg(page_state, infobuff.State);
+
+             print_flg(protection, (infobuff.Protect & 0xff));
+             if (infobuff.Protect & ~0xff) {
+                 print_flg(p_modifiers, (infobuff.Protect & ~0xff));
+             }
+
+             print_flg(page_type, infobuff.Type);
+         }
+         fprintf(stderr, "\n");
+
+ #if 0
+         fprintf(stderr, "%p %p a%3x %p s%5x p%3x t%7x\n",
+                 infobuff.BaseAddress,
+                 infobuff.AllocationBase,
+                 infobuff.AllocationProtect,
+                 infobuff.RegionSize,
+                 infobuff.State,
+                 infobuff.Protect,
+                 infobuff.Type
+             );
+ #endif
+         addr = (LPCBYTE) infobuff.BaseAddress + infobuff.RegionSize;
+         if (++i >= 500) /* failsafe */
+             break;
+     }
+     fprintf(stderr, "-VQ-end\n");
+ }
+ #endif /*DEBUG_VQ*/
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /mnt/prj/pg/cvsmirror/pg/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.583
diff -c -r1.583 postmaster.c
*** src/backend/postmaster/postmaster.c    26 Jun 2009 20:29:04 -0000    1.583
--- src/backend/postmaster/postmaster.c    7 Jul 2009 09:54:24 -0000
***************
*** 3645,3650 ****
--- 3645,3657 ----
          elog(LOG, "could not close handle to backend parameter file: error code %d",
               (int) GetLastError());

+     {
+         /* reserve shared memory area before ResumeThread() */
+         /* XXX: if it fail ? */
+         extern void pgwin32_ReserveSharedMemory(HANDLE);
+         pgwin32_ReserveSharedMemory(pi.hProcess);
+     }
+
      /*
       * Now that the backend variables are written out, we start the child
       * thread so it can start initializing while we set up the rest of the

Re: Unknown winsock error 10061

From
Dave Page
Date:
When the server starts, it should also spew out the initial shmem
segment ID and address  - did you get them? They may go to stderr
rather than the log, because they're output so early in the startup. I
assume they're the same because one of the attaches seems to work
fine.

2009/7/8 Wojciech Strza=C5=82ka <wstrzalka@gmail.com>:
> And the result is:
>
> 2009-07-08 14:26:00 CEST PID:9612 DEBUG: =C2=A000000: forked new backend,=
 pid=3D8120 socket=3D948
> 2009-07-08 14:26:00 CEST PID:9612 LOCATION: =C2=A0BackendStartup, .\src\b=
ackend\postmaster\postmaster.c:3029
> *** Finished restoring shared memory vars in restore_backend_variables (k=
ey=3D256, addr=3D02400000)
> FATAL: =C2=A0could not reattach to shared memory (key=3D256, addr=3D02400=
000): 487
> 2009-07-08 14:26:00 CEST PID:9612 DEBUG: =C2=A000000: reaping dead proces=
ses
> 2009-07-08 14:26:00 CEST PID:9612 LOCATION: =C2=A0reaper, .\src\backend\p=
ostmaster\postmaster.c:2184
> 2009-07-08 14:26:00 CEST PID:9612 DEBUG: =C2=A000000: server process (PID=
 8120) exited with exit code 1
> 2009-07-08 14:26:00 CEST PID:9612 LOCATION: =C2=A0LogChildExit, .\src\bac=
kend\postmaster\postmaster.c:2653
> 2009-07-08 14:26:01 CEST PID:9612 DEBUG: =C2=A000000: forked new backend,=
 pid=3D9952 socket=3D948
> 2009-07-08 14:26:01 CEST PID:9612 LOCATION: =C2=A0BackendStartup, .\src\b=
ackend\postmaster\postmaster.c:3029
> *** Finished restoring shared memory vars in restore_backend_variables (k=
ey=3D256, addr=3D02400000)
> *** Finished reattaching shared memory segment in PGSharedMemoryReAttach =
(key=3D256, addr=3D02400000)
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: postgres child[9952=
]: starting with (
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0BackendRun, .\src\backe=
nd\postmaster\postmaster.c:3384
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: =C2=A0 =C2=A0 =C2=
=A0 =C2=A0postgres
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0BackendRun, .\src\backe=
nd\postmaster\postmaster.c:3387
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: =C2=A0 =C2=A0 =C2=
=A0 =C2=A0-v196608
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0BackendRun, .\src\backe=
nd\postmaster\postmaster.c:3387
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: =C2=A0 =C2=A0 =C2=
=A0 =C2=A0-y
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0BackendRun, .\src\backe=
nd\postmaster\postmaster.c:3387
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: =C2=A0 =C2=A0 =C2=
=A0 =C2=A0masterdb
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0BackendRun, .\src\backe=
nd\postmaster\postmaster.c:3387
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: )
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0BackendRun, .\src\backe=
nd\postmaster\postmaster.c:3389
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: InitPostgres
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0PostgresMain, .\src\bac=
kend\tcop\postgres.c:3333
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: my backend id is 5
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0SharedInvalBackendInit,=
 .\src\backend\storage\ipc\sinvaladt.c:316
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: StartTransaction
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0ShowTransactionState, .=
\src\backend\access\transam\xact.c:4073
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: name: unnamed; bloc=
kState: =C2=A0 =C2=A0 =C2=A0 DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0,=
 nestlvl: 1, children:
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0ShowTransactionStateRec=
, .\src\backend\access\transam\xact.c:4111
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: CommitTransaction
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0ShowTransactionState, .=
\src\backend\access\transam\xact.c:4073
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: name: unnamed; bloc=
kState: =C2=A0 =C2=A0 =C2=A0 STARTED; state: INPROGR, xid/subid/cid: 0/1/0,=
 nestlvl: 1, children:
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0ShowTransactionStateRec=
, .\src\backend\access\transam\xact.c:4111
> 2009-07-08 14:26:01 CEST PID:9952 DEBUG: =C2=A000000: parse <unnamed>: SH=
OW TRANSACTION ISOLATION LEVEL
> 2009-07-08 14:26:01 CEST PID:9952 LOCATION: =C2=A0exec_parse_message, .\s=
rc\backend\tcop\postgres.c:1117
> 2009-07-08 14:26:01 CEST PID:9952 STATEMENT: =C2=A0SHOW TRANSACTION ISOLA=
TION LEVEL
>
>
>
> --
> Pozdrowienia,
> =C2=A0Wojciech Strza=C5=82ka
>
>



--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
Dave Page
Date:
On Wed, Jul 8, 2009 at 2:03 PM, Tsutomu Yamada<tsutomu@sraoss.co.jp> wrote:

> 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.

Ooh, interesting. I put a patched build at
http://uploads.enterprisedb.com/download.php?file=abb85b99acc1cf1668e3ff35bdb665ee

It has DEBUG_VQ defined. Wojciech - can you give it a try please?

Thanks Yamada-san.


--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Unknown winsock error 10061

From
wstrzalka
Date:
Looks very good by now.

  I'll test the version for a few days in my regular work and will
post more feedback here.

On 8 Lip, 17:37, dp...@pgadmin.org (Dave Page) wrote:
> On Wed, Jul 8, 2009 at 2:03 PM, Tsutomu Yamada<tsut...@sraoss.co.jp> wrot=
e:
> > 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.
>
> Ooh, interesting. I put a patched build athttp://uploads.enterprisedb.com=
/download.php?file=3Dabb85b99acc1cf1668e...
>
> It has DEBUG_VQ defined. Wojciech - can you give it a try please?
>
> Thanks Yamada-san.
>
> --
> Dave Page
> EnterpriseDB UK: =A0http://www.enterprisedb.com
>
> --
> Sent via pgsql-bugs mailing list (pgsql-b...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/p=
gsql-bugs

Re: Unknown winsock error 10061

From
wstrzalka
Date:
So as promised - the patch is very stable. No more memory problems,
neither any other issues.

  Great job Yamada-san!!!!

  Dave - can I assume you'll manage this fix to be pushed to official
release?


On 9 Lip, 17:08, wstrzalka <wstrza...@gmail.com> wrote:
> =A0 Looks very good by now.
>
> =A0 I'll test the version for a few days in my regular work and will
> post more feedback here.
>
> On 8 Lip, 17:37, dp...@pgadmin.org (Dave Page) wrote:
>
> > On Wed, Jul 8, 2009 at 2:03 PM, Tsutomu Yamada<tsut...@sraoss.co.jp> wr=
ote:
> > > 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.
>
> > Ooh, interesting. I put a patched build athttp://uploads.enterprisedb.c=
om/download.php?file=3Dabb85b99acc1cf1668e...
>
> > It has DEBUG_VQ defined. Wojciech - can you give it a try please?
>
> > Thanks Yamada-san.
>
> > --
> > Dave Page
> > EnterpriseDB UK: =A0http://www.enterprisedb.com
>
> > --
> > Sent via pgsql-bugs mailing list (pgsql-b...@postgresql.org)
> > To make changes to your subscription:http://www.postgresql.org/mailpref=
/pgsql-bugs