Re: win2k, service, pg_ctl, popen, etc

Claudio Natoli wrote:
>
> > Have you looked at find_other_exec(). We call find_my_exec(), then
>
> Yes. IIRC, I assisted you with the recent refactoring of exec.c.
>
>
> > assuming that works, we go ahead and check versions. We don't loop back
> > and keep poking around until we find a matching version.
> >
> > This code was added particularly so relocable installs don't get wacked
> > out, and you can bet Win32 will wack it out even more than unix folks.
>
> GetMFN used in find_my_exec will continue to allow relocatable installs.
> What it does is remove any ambiguity over having found the correct location
> of the running binary. In this case, all that the version check then
> achieves (other than consistency between *nix and Win32) is to make sure
> that people don't mix different versions of PostgreSQL binaries in the same
> directory, which IMHO seems like overkill.
>
>
> > I am not willing to loosen that check for Win32 --- in fact I
> > would like that check especially for Win32 where users are less
> experienced.
>
> That is clear. I lack any concern for users who mix PostgreSQL binaries of
> different versions in the same directory, but you maintain concern. We
> simply disagree.

We have received several bug reports of binary mismatches so tightening
it seems logical, and we are doing it in all cases:

pg_ctl finding postmaster
postmaster finding postgres
initdb finding postgres
pg_dumpall finding pg_dump

It has _nothing_ to do with any weakness in finding our own binary path
under Unix.

It all happens in exec.c. The test is simple in Unix. If it isn't
simple in Win32, then we need to work harder to make it happen.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073