Re: postmaster.pid

Magnus Hagander said:
>> > 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).

cheers

andrew




---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match