Re: Fix for pg_upgrade user flag

Robert Haas wrote:
> On Sat, May 7, 2011 at 9:50 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce(at)momjian(dot)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 system
postgres=> alter user postgres nosuperuser;
ALTER ROLE

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +