I've seen it happen on a wide range of win2k3 servers. From a fresh
image with nothing but VMWare tools under Add/Remove Programs, to a
heavily used shared dev server with MSVC, Cygwin, and tons of other
stuff. Some of our beta testers have also seen the issue. In fact I
can't really think of any win2k3 machine where it *had* worked. I
suspect the main reason reports of this failure are relatively rare is
that most people use the one-click installer which sets it up to run as
a non-administrator service account. (That's superior in many ways, but
it is not always an option for me.)
It looks like something that happens with Win2k3 only; XP had the user
instead of Administrators in the DACL, and Vista appears to have the
Session. I guess that's the only place that "AddUserToDacl" was even
necessary in the first place? I dunno.
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Tuesday, October 20, 2009 9:45 AM
> To: Dave Page
> Cc: Andrew Dunstan; Jesse Morris; pgsql-bugs@postgresql.org; Magnus
> Hagander
> Subject: Re: [BUGS] Re: BUG #5065: pg_ctl start fails as
administrator,
> with "could not locate matching postgres executable"
>=20
> Dave Page <dpage@pgadmin.org> writes:
> > On Tue, Oct 20, 2009 at 3:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Do we have any idea why?
>=20
> > Honestly? No. I have a vague hand-wavy idea about there being
> > something preventing us properly modifying the token of an existing
> > process in some configurations, but nothing even remotely
jello-like,
> > let alone concrete.
>=20
> After re-reading the thread I am struck by Jesse's comment that the
> current coding never worked at all for him. It seems like that must
> indicate an environment difference or installed-software difference
> compared to the setups where it does work. (Antivirus maybe?)
>=20
> Seems like it would be worth the trouble to identify exactly what the
> critical difference is.
>=20
> regards, tom lane
