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