Hi,
On Wednesday 25 August 2004 19:53, Andrew Dunstan wrote:
> Joerg Hessdoerfer wrote:
> >Well, wouldn't it be better then to do an OS-dependant check for a running
> >postmaster, which could use kill() on IMHO broken systems where it's not
> > easy to determine the processname for a PID, and more elaborate checking
> > on others. On Windows, there's OpenProcess et al, on Linux, one could
> > resort to /proc. I didn't develop on too many others, but there should be
> > possibilities for those, too.
>
> At this stage in the dev cycle I don't think so - might be worth
> improving the robustness post 8.0. Assuming you have access to /proc can
> be dangerous too - even if it's there (and in some jail/chroot type
> environments it isn't) .
>
> One thought I did have was that it might be worth ignoring the .pid file
> is its mtime was older than the system boot time, assuming that both
> could be determined portably and reliably.
>
> cheers
>
> andrew
Ok, your objections are sound. But I just thought a little bit more about
this. What's your opinion of this:
On successful startup, postmaster opens a special TCP socket to listen on from
127.0.0.1 only, and notes the port no. in postmaster.pid, too.
On startup, postmaster reads postmaster.pid, if present, and tries to connect
to the mentioned port. If the connection fails, no postmaster is present, so
continue startup. If connection is accepted, the 'original' postmaster sends
a defined Message a la 'PostgreSQL postmaster version 8.1.0' down the socket
and closes the connection. Only if this is received in a reasonable time, we
are sure to have a postmaster running and should abort startup, else we can
safely continue.
This should be highly portable, and also catches the case where the postmaster
just crashed without the system rebooting (where the mtime check would fail,
too).
Greetings,
Jörg
--
Leading SW developer - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW: http://www.sea-gmbh.com