Thread: Unknown winsock error 10061
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ;)
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
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
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
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
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
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