Andrew Dunstan <and...@dunslane.net> writes:
> I had a brief talk with Magnus the other day, and I have just spent more
> time looking over this. This is a fairly narrow failure case, with a not
> so narrow proposed solution. Making pg_ctl re-exec itself whenever we
> see that we're running as an admin user is a very broad brush approach,
> since the problem is restricted to cases where we have a config-only
> data directory. I'm particularly concerned about the possible effect
> that might have on pg_ctl when it's running as a service controller, and
> I'm not prepared to commit anything like the current patch without a
> great deal more testing.
Good point.
> A temporary bandaid might be to do the
> detection of admin privileges and go back to doing what we did there
> before we got adjust_data_dir() for that case. That at least should work
> no worse than what we have now.
Unless I'm missing something, pg_ctl basically doesn't work with
config-only directory setups before 9.2: since it has no way to find the
postmaster.pid file, any case that waits for the postmaster to start or
stop will fail in a confusing fashion. So the fact that the case still
doesn't work on Windows doesn't constitute a regression; in fact, it
might be *more* user-friendly this way, since you'll get an error rather
than obscure misbehavior. Rather than applying a hasty band-aid,
I think it's probably better to sit back and think about a solution
for 9.3.
BTW, one idea that occurs to me is to bypass the problem by skipping
the server's no-root-privileges check when the postmaster is given the
-C switch. (This shouldn't pose a security hazard, since reading the
config files is something a root-privileged caller could do anyway.)
I don't immediately see a non-ugly way to do that in the current server
code structure, but maybe somebody else will have an idea.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
