Re: postmaster.pid

> >> > But sure, we don't really care if it's a postmaster. Then
> >> > OpenProcess() is probably the best way, yes.
> >>
> >> Au contraire!!  One of the problems with the Unix 
> implementation is 
> >> that you *can't* tell for sure if the target process is a 
> postmaster.  
> >> See past discussions about how startup occasionally fails 
> because we 
> >> get fooled by the PID mentioned in postmaster.pid now belonging to 
> >> pg_ctl or some other Postgres-owned process.
> >>
> >> This is a place where the Windows version can actually be 
> better than 
> >> the Unix one.  Please fix it and stop imagining that your 
> charter is 
> >> to duplicate a particular Unix syscall bug-for-bug.
> >
> > Ok, if you say so :-) I had the general impression we 
> wanted that. But 
> > then let's go with the 
> > send-signal-0-down-the-pipe-and-ignore-it-in-the-backend. :-)
> >
> 
> [away from my desk so can't check right now] What do we get 
> back down the pipe? Unless it's something that identifies 
> that we are talking to a postmaster will we be further 
> advanced than the Unix case? (I agree that talking on the 
> pipe would be more robust than the simple OpenProcess() test, 
> regardless of this point).

We send the signal numberb ack down the pipe. If se send SIGHUP, we get
SIGHUP back. Etc.

And it would still be further advanced - we'd know it was a pg process
because it was listening on \\.\pipe\pgsgnal_<pid>.


//Magnus

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org