Robert Treat wrote:
> On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander wrote:
> > On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
> >> Robert Treat writes:
> >>> Did anything ever come of this discussion?
> >>
> >> I think it's a TODO --- nothing done about it as yet, AFAIR.
> >>
> >>> On one of
On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander wrote:
> On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
>> Robert Treat 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
On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
> Robert Treat 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. T
Robert Treat 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 dumping roles in
On Thu, Jan 6, 2011 at 10:08 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian 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 buggin
Tom Lane wrote:
> Bruce Momjian 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 o
Bruce Momjian 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 that could arise
bruce wrote:
> Robert Haas wrote:
> > On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian 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
On Thu, Jan 6, 2011 at 3:54 PM, Bruce Momjian 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 impossible, it just r
Robert Haas wrote:
> On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian 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'
On Thu, Jan 6, 2011 at 1:59 PM, Bruce Momjian 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 could Florian.
Robert Haas wrote:
> On Wed, Jan 5, 2011 at 11:08 PM, Tom Lane 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 st
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 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 r
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
On Jan6, 2011, at 04:13 , Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian 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 Wed, Jan 5, 2011 at 11:08 PM, Tom Lane 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 FOREIGN KEY N
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 cas
Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian 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 SES
Robert Haas writes:
> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian 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 b
Robert Haas wrote:
> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian 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 th
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian 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
consid
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 wh
On Dec13, 2010, at 16:40 , Tom Lane wrote:
> Florian Pflug 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 .. SE
Florian Pflug 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 do, I
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_upgra
On Sun, Dec 12, 2010 at 11:01 AM, Tom Lane 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 at all. You'v
On Dec12, 2010, at 17:01 , Tom Lane wrote:
> Florian Pflug 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,
Florian Pflug 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 that the
28 matches
Mail list logo
