Robert Haas wrote:
> On Sat, May 7, 2011 at 9:50 AM, Robert Haas <[email protected]> wrote:
> > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <[email protected]> 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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
