Re: Fix for pg_upgrade user flag

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. +