Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
| От | Florian Pflug |
|---|---|
| Тема | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |
| Дата | |
| Msg-id | 29149C56-20DC-46F6-A632-CA95CCB2C49A@phlo.org обсуждение исходный текст |
| Ответ на | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: Problem with pg_upgrade (8.4 -> 9.0) due to
ALTER DATABASE SET ROLE
|
| Список | pgsql-hackers |
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. > 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. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: