Robert Haas wrote:
> On Sat, May 7, 2011 at 9:50 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >> The attached, applied patch checks that the pg_upgrade user specified is
> >> a super-user. ?It also reports the error message when the post-pg_ctl
> >> connection fails.
> >>
> >> This was prompted by a private bug report from EnterpriseDB.
> >
> > It strikes me that it's fairly crazy to think you're going to be able
> > to catch all the possible errors the server might throw this way.
> > Don't we need some way of letting the actual server errors leak out?
>
> Or, hmm. Maybe you just did that. If so, never mind. :-)
What I did was to report the errors of our first database probe after we
started the server --- for some reason, that code was not reporting the
libpq error message, while all other failed connections did.
The second change was to only run pg_upgrade as a database super-user,
and hopefully that will avoid odd pg_dump error messages.
One question I have is why we even bother to allow the database username
to be specified? Shouldn't we just hard-code that to 'postgres'? Is
there any reason to allow another username to be used? You can't drop
the postgres user but you can remove super-user permissions from it so
maybe we have to continue allowing it:
postgres=> drop user postgres;ERROR: cannot drop role postgres because it is required by the database systempostgres=>
alteruser postgres nosuperuser;ALTER ROLE
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
