On Fri, Oct 16, 2009 at 1:08 AM, Jesse Morris <jmorris@coverity.com> wrote:
> I went back to the version that supposedly initially fixed this issue,
> but I couldn't get it to work either. =A0So I think the DACL adjustment
> code was always broken. =A0The DACL stuff that both Cygwin and Active
> Perl use to simulate *nix file permissions masks this error, so any
> test framework that uses them would get false negatives on this bug.
> Since these DACLs are inheritable, a workaround is to run pg_ctl as a
> child process of Active Perl or Cygwin. =A0 The comments indicated
> pg_ctl & initdb were already trying to do the same thing themselves
> (that is, add the current user to the DACLs) but it didn't actually
> work on any of the systems I tried it on.
In fairness it wasn't entirely broken as it fixed the problem for the
majority of people. Clearly there's room for improvement though as we
do still see the problem occasionally.
> I think that a number of other people have seen this bug; search for
> "FATAL: postgres - could not locate matching postgres executable."
> But that message is so misleading is probably why it seems nobody has
> properly diagnosed it as a permissions issue before. =A0I didn't do
> anything to fix pg_ctl's error reporting. =A0:D
We figured out that it was a permissions problem after a *lot* of back
and forth with Microsoft's developer support engineers - that's what
led to the AddUserToDacl fix. What didn't then happen was further
investigation into the handful of later reports of similar issues -
unfortunately that can be extremely difficult as few users are
experienced Windows programmers. It's great to see someone that is has
seen the problem and taken the time to figure it out :-).
> The patch:
>
> ------begin patch------
:-(. Unfortunately inlining the patch in the email has munged it
beyond usability. Can you resend it as an attachment please?
Thanks!
--=20
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
