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
>
