Re: Crazy W2000 service behavior - Mailing list pgsql-hackers-win32
From | Christian Klemke |
---|---|
Subject | Re: Crazy W2000 service behavior |
Date | |
Msg-id | 001c01c46e2d$b5c1d7e0$4701a8c0@NTBKCKLEMKE Whole thread Raw |
In response to | Re: Crazy W2000 service behavior ("Gary Doades" <gpd@gpdnet.co.uk>) |
List | pgsql-hackers-win32 |
Hi everyone, here is what came to my mind when looking at the recent postings: Some DLLs have special initialization functions which have to be called before any other function call. E.g. if an application wants to use functions from the WinSock2 library, it must call WSAStartup(...) first. Usually these initialization calls are application local, i.e. any application that uses the corresponding library has to do so independently of any other app using the same library (or it will experience errors). But DLLs are free to use a global initialization strategy, which means you can theoretically use them perfectly as long as they has been initialized correctly by another application at some point in the past. Of course, relying on this would never guarantee your own application to run safely, but bugs of this kind might appear or not appear depending on what other apps did before. Maybe some module in Postgres make use of a such DLL (leaving out the correct initialization), but it is a very frequently used one (maybe even used by the Explorer or some other standard application), so it only fails if started at a early stages of system startup (e.g. by the service manager). Another possible trap specific to services is to make (direct or immediate) use of another service without waiting for it to be ready. Fortunately, Windows supports a mechanism to define service dependencies and handles the proper call sequence automatically (blocking services until all neccessary steps are taken). I have not worked in this area for a long time, but I remember that in NT 4, when I needed to use TCP/IP I had to declare a dependency to the TCP/IP servive, which in turn depended on the network service etc. This kind of dependency definition is optional but can be handled very easily by providing appropriate parameters in the service registration process. The same remarks as above (about succeeding or failing) apply here. Once the graphical user interface has started, all relevant low-level services are already active, and so Postgres can use them. But if started earlier in the boot process, some of them might still be unloaded or might not yet have properly start up (and therefore cause errors). I must admit I didn't have time to look at the Postgres sources (especially the Win32 service code), so these are just guesses. I hope they are helpful anyway. Regards, Christian. P.S. Congratulations to the Postgres Win32 team, you have done a great job so far. ----- Original Message ----- From: "Gary Doades" <gpd@gpdnet.co.uk> To: "pgsql win32 hack" <pgsql-hackers-win32@postgresql.org> Sent: Tuesday, July 20, 2004 8:52 AM Subject: Re: [pgsql-hackers-win32] Crazy W2000 service behavior > On 20 Jul 2004 at 7:57, Stasys Adiklis wrote: > > > > > All the paths are OK (system ones). Let's try autostartup: > > > > 1. [pg_ctl unregister, ]pg_ctl register -U pgsql -P password. Service > > startup type: Automatic. > > 2. reboot > > 3. service is not running. Event Viewer (Source: Service Control Manager): > > Description: The PostgreSQL service hung on starting. > > Description: The PostgreSQL service terminated unexpectedly. It has done > > this 1 time(s). The following corrective action will be taken in 0 > > milliseconds: No action. > > > > A bit later i did: runas /user:pgsql cmd, pg_ctl start and it worked. > > Stopped it with Ctrl+Break (i know i should have pg_ctl stop, but...). A bit > > later i tried to launch it again with runas /user:pgsql "pg_ctl start" and > > got that "failure to initialize" error pop-up. Event Viewer (Source: > > Application Popup): > > Description: Application popup: postmaster.exe - Application Error : The > > application failed to initialize properly (0xc0000142). Click on OK to > > terminate the application. > > > > Ah now that you have said 0xc0000142 (not 0x0000142) it makes a little > more sense. Searching MSDN these errors relate to loading of DLLs. Either > the wrong version, or trying to use a DLL before it is initialised. > > If it were a versioning problem with a system DLL I think it would never > work. So we are left with an intermittent timing/synchronisation problem. > Weirdly it only *seems* to happen under Win2K. > > I don't know enough about the startup sequence of postgres to go further at > this stage, but I would guess that postmaster or one of the postgres > processes is not waiting enough or syncing properly before attempting DLL > calls. This might also explain why it works the second time when stuff > (including the DLLs) are more likely to be in memory and start up faster. > > Debugging timing/sync problems can be tricky (if this is indeed the > problem). The guys that know lots more than me will have to look at this > one. > > Cheers, > Gary. > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
pgsql-hackers-win32 by date: