Robert Treat wrote:
On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Feb 28, 2011 at 06:21, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Treat r...@xzilla.net writes:
Did anything ever come of this discussion?
I think it's a TODO --- nothing done about it
On Mon, Feb 28, 2011 at 06:21, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Treat r...@xzilla.net writes:
Did anything ever come of this discussion?
I think it's a TODO --- nothing done about it as yet, AFAIR.
On one of the databases I
was upgrading, I ran into a similar problem with roles
On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Feb 28, 2011 at 06:21, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Treat r...@xzilla.net writes:
Did anything ever come of this discussion?
I think it's a TODO --- nothing done about it as yet, AFAIR.
On one
On Thu, Jan 6, 2011 at 10:08 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
We could modify pg_dump to emit RESET AUTHORIZATION in --binary-upgrade
mode. I am unclear if that might cause some other problems though.
I finally figured out
Robert Treat r...@xzilla.net writes:
Did anything ever come of this discussion?
I think it's a TODO --- nothing done about it as yet, AFAIR.
On one of the databases I
was upgrading, I ran into a similar problem with roles that are set as
roles. The problem seems to stem from pg_dumpall
On Jan6, 2011, at 04:13 , Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@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
On Jan6, 2011, at 05:08 , Tom Lane wrote:
I think an appropriate response would be to prevent ALTER DATABASE SET
ROLE. I really cannot believe that there are any situations where
that's a good idea.
I explained up-thread why, in my situation, doing this *is* a perfectly
good idea. You have
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 br...@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
Robert Haas wrote:
On Wed, Jan 5, 2011 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could take the approach somebody was just espousing about
Our job is to prevent the user from *accidentally*
shooting themselves in the foot.
I don't see how you can compare those two cases
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Well, if everyone who logs in gets the same username, you can easily
conclude that trying to dump/restore the database will cause problems if
you have objects in there that are not owned by that user.
I can't, and neither
Robert Haas wrote:
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Well, if everyone who logs in gets the same username, you can easily
conclude that trying to dump/restore the database will cause problems if
you have objects in there that are not owned by that user.
On Thu, Jan 6, 2011 at 3:54 PM, Bruce Momjian br...@momjian.us wrote:
Well, we usually tell people to restore as super-user, particularly
pg_dumpall, but in this case, it is impossible. Certainly pg_upgrade
requires it, which is the root of the problem.
True. Although it's not really
bruce wrote:
Robert Haas wrote:
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
Well, if everyone who logs in gets the same username, you can easily
conclude that trying to dump/restore the database will cause problems if
you have objects in there that are not
Bruce Momjian br...@momjian.us writes:
We could modify pg_dump to emit RESET AUTHORIZATION in --binary-upgrade
mode. I am unclear if that might cause some other problems though.
I finally figured out what was really bugging me about that proposal:
it's a one-shot hack for fixing one problem
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
We could modify pg_dump to emit RESET AUTHORIZATION in --binary-upgrade
mode. I am unclear if that might cause some other problems though.
I finally figured out what was really bugging me about that proposal:
it's a one-shot hack for
Florian Pflug wrote:
Hi
I've just ran into a problem while upgrading from 8.4 to 9.0.
pg_upgrade aborted during the step Adding support functions to new
cluster with ERROR: permission denied for language c error.
Unfortunately, the log didn't include the name of the database where
the
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@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
Robert Haas wrote:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@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.
On 01/05/2011 11:08 PM, Tom Lane wrote:
If they want to deliberately shoot themselves in the foot by hosing the
login system like that, it's not our job to prevent it. But it's not
our job to try to work around it, either.
I think this is especially true in this
On Wed, Jan 5, 2011 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could take the approach somebody was just espousing about
Our job is to prevent the user from *accidentally*
shooting themselves in the foot.
I don't see how you can compare those two cases with a straight face.
In the
Florian Pflug f...@phlo.org writes:
On Dec13, 2010, at 00:16 , Robert Haas wrote:
And in fact it strikes me that we might not have much choice about how
to fix this. I think we are not going to retroactively change the
behavior of ALTER DATABASE .. SET ROLE in a released version, but yet
we
On Dec13, 2010, at 16:40 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Dec13, 2010, at 00:16 , Robert Haas wrote:
And in fact it strikes me that we might not have much choice about how
to fix this. I think we are not going to retroactively change the
behavior of ALTER DATABASE ..
Hi
I've just ran into a problem while upgrading from 8.4 to 9.0.
pg_upgrade aborted during the step Adding support functions to new cluster
with ERROR: permission denied for language c error. Unfortunately, the log
didn't include the name of the database where the error occurred, so it took
Florian Pflug f...@phlo.org writes:
pg_upgrade aborted during the step Adding support functions to new cluster
with ERROR: permission denied for language c error. Unfortunately, the log
didn't include the name of the database where the error occurred, so it took
me a while to figure out
On Dec12, 2010, at 17:01 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
pg_upgrade aborted during the step Adding support functions to new cluster
with ERROR: permission denied for language c error. Unfortunately, the
log didn't include the name of the database where the error
On Sun, Dec 12, 2010 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This is about like arguing that pg_dump and pg_upgrade should still work
after you've done delete from pg_proc;. Superusers are assumed to
know what they're doing and not break fundamental operations.
No, it isn't like that
On Dec13, 2010, at 00:16 , Robert Haas wrote:
And in fact it strikes me that we might not have much choice about how
to fix this. I think we are not going to retroactively change the
behavior of ALTER DATABASE .. SET ROLE in a released version, but yet
we do, I think, want to make pg_upgrade
29 matches
Mail list logo
