Florian Pflug wrote:
> On Jan6, 2011, at 04:13 , Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >>> I think pg_dumpall would have failed with this setup too, so I don't see
> >>> this as a pg_upgrade bug, nor something that I am willing to risk adding
> >>> to pg_upgrade.
> >>
> >> If adding RESET SESSION AUTHORIZATION fixes the bug, I think we should
> >> consider doing that.
> >
> > If we add every fix that could conceivably break a pg_dumpall restore,
> > pg_upgrade will be less stable than it is now. I don't see why adding
> > this should be any different.
>
> The issue is more complicted. In my situation, it's not the pg_dumpall
> restore that's failing, but rather pg_upgrade's attempt to install
> the support functions necessary for the upgrade.
>
> But in principle, you're right I think. pg_dumpall *would* fail if my
> database contained any objects that required superuser privileges to
> create, like C-language functions.
Right, it was only the pg_upgrade support functions that failed first.
> > If you want to argue that pg_dumpall should be doing it, that is a
> > separate issue and not related to pg_upgrade.
>
> I think both need the fix.
Actually, pg_dump would need to be doing it, so would need a line in
every pg_dump file with a RESET SESSION AUTHORIZATION, but because the
fact that the command actually reset the username suprised many of us,
you would also need an SQL command stating why it is there. And at that
point, it seems like complete overkill.
Also, remember, pg_upgrade does as liittle as possible (like me :-) )
and relies as much as possible on the existing Postgres facilities to
improve its reliability and reduce the churn needed for each new major
release.
As far as telling you what database you failed in, pg_upgrade can't
because it blindly runs the pg_dumpall file through psql and just exits
on _any_ error, hence the failure you saw, but we don't know what
database you were in when the failure happened. We would need to modify
psql to report the database in the error message.
Looking at your use case of ALTER DATABASE SET, shouldn't you be using
the new default schema object permission feature?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
