Re: pg_ctl -D canonicalization

> > It seems pg_ctl calls canonicalize_path() only on the path as being
> > used to access for example the pid file, and not the path
> that is sent
> > along to the postmaster.
> > Specifically, this causes failure on win32 when a path is
> passed with
> > a trailing backslash, when it's inside quotes such as:
> > pg_ctl start -D "c:\program fiels\postgresql\data\"
> >
> > The quotes are of course necessary since there are spaces in the
> > filename. In my specific case the trailing backslash is
> automatically
> > added by windows installer. but other cases when the backslash is
> > added can easily be seen...
> >
> > Attached patch makes pg_ctl call canonicalize_path() on the path as
> > passed on the commandline as well.
> >
> > I have only tested this on win32, where it appears to work fine. I
> > think it would be good on other platsforms as well which is why I
> > didn't #ifdef it. If not, then please add #ifdefs.
>
> Uh, isn't the proper fix to fix the postmaster's handling of -D paths?

Nope.

The problem is that in this case, pg_ctl gets the path:
c:\program files\postgresql\data\"

(not unbalanced quotes). Yes, win32 commandline quoting is horrible.
Anyway. then it properly quotes this for the commandline:
"c:\program files\postgresql\data\""

and you can see where that breaks down...

Another option would be simple check to simply strip the " (and the
trailing backslash too, probably, to make things safer at the next
step). I just thought it'd be cleaner to use canonicalize_path(). But
it's just the trailing quote stuff that causes the problem. (See the
second step in canonicalize_path() where this has been noticed befoer,
followed by the trim-trailing part which would also be nice).

(Everything works if you register it as a service because then it uses
pg_data and not pgdata_opt. This is just when you start things manually,
which is why we missed it before...)

//Magnus