Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I deleted valuable data from wrong table :) pretty common problem i
>> think. Guy on #postgresql at freenode told me that my data is still
>> there, but tricky part is how to undo my delete. I'm using pg 7.4.7 on
>> fbsd, i dont' use any specia
I deleted valuable data from wrong table :) pretty common problem i
think. Guy on #postgresql at freenode told me that my data is still
there, but tricky part is how to undo my delete. I'm using pg 7.4.7 on
fbsd, i dont' use any special config and pg_xlog is fine. I hope there
is a solution :)
That
Hi all,
I couldn't find anything related to my problem on web or irc, so i'm
posting here.
I deleted valuable data from wrong table :) pretty common problem i
think. Guy on #postgresql at freenode told me that my data is still
there, but tricky part is how to undo my delete. I'm using pg 7.4.7 on
On Mon, 2004-05-24 at 16:03, Christopher Kings-Lynne wrote:
> > Isn't it just enough to prevent the user with userid 1 from losing the
> > superuser status. If one want to allow it one could prevent it just when
> > doing the ALTER USER stuff and allow it when editing pg_shadow directly.
> > Or
IMHO we (that is Christopher, me and others maintaining easy to (mis)use
tools) should warn the users about what they're going to do.
Yes, I'm going to have to modify phpPgAdmin methinks.
Chris
---(end of broadcast)---
TIP 9: the planner will ignore
Christopher Kings-Lynne wrote:
The mistake has only come up two or three times that I can remember,
which doesn't elevate it to the category of stuff that I want to install
a lot of mechanism to prevent. Especially not mechanism that would get
in the way of reasonable uses. I think it's sufficien
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Hmmm - I agree it's difficult, but somehow I think it's something we
should do. Just imagine if some major user of postgres did it - they'd
be screaming blue murder...
Shrug. Superusers can *always* shoot themselves in the foo
On Mon, May 24, 2004 at 11:23:09AM -0700, Joe Conway wrote:
> Tom Lane wrote:
> >Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> >>Hmmm - I agree it's difficult, but somehow I think it's something we
> >>should do. Just imagine if some major user of postgres did it - they'd
> >>be screamin
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Hmmm - I agree it's difficult, but somehow I think it's something we
should do. Just imagine if some major user of postgres did it - they'd
be screaming blue murder...
Shrug. Superusers can *always* shoot themselves in the foot
Isn't it just enough to prevent the user with userid 1 from losing the
superuser status. If one want to allow it one could prevent it just when
doing the ALTER USER stuff and allow it when editing pg_shadow directly.
Or maybe have some guc variable that write locks the user with id 1.
That gets
On Mon, 24 May 2004, Tom Lane wrote:
> I think the cure would probably be worse than the disease. To make any
> serious attempt at preventing remove-the-last-superuser, we'd have to
> make operations on pg_shadow grab exclusive lock. For instance, you
> couldn't allow two backends to DROP USER i
The mistake has only come up two or three times that I can remember,
which doesn't elevate it to the category of stuff that I want to install
a lot of mechanism to prevent. Especially not mechanism that would get
in the way of reasonable uses. I think it's sufficient to have a
recovery procedure.
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Hmmm - I agree it's difficult, but somehow I think it's something we
> should do. Just imagine if some major user of postgres did it - they'd
> be screaming blue murder...
Shrug. Superusers can *always* shoot themselves in the foot in Postg
Ð ÐÐÐ, 24.05.2004, Ð 16:12, Tom Lane ÐÐÑÐÑ:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > A guy on the IRC channel managed to accidentally click the wrong thing
> > in phpPgAdmin and managed to remove superuser privileges from his only
> > superuser.
>
> No sweat; we've seen this one
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> No sweat; we've seen this one before.
> Should this situation be prevented though?
I think the cure would probably be worse than the disease. To make any
serious attempt at preventing remove-the-last-superuser, we'd have to
make operations o
No sweat; we've seen this one before.
Should this situation be prevented though?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> A guy on the IRC channel managed to accidentally click the wrong thing
> in phpPgAdmin and managed to remove superuser privileges from his only
> superuser.
No sweat; we've seen this one before.
Stop postmaster and start a standalone backend
On Mon, May 24, 2004 at 09:54:20PM +0800, Christopher Kings-Lynne wrote:
> in phpPgAdmin and managed to remove superuser privileges from his only
> superuser.
>
> We thought and though but it seems that there is no way to recover from
> this situation except a re-init and reload. And what user
Hi guys,
A guy on the IRC channel managed to accidentally click the wrong thing
in phpPgAdmin and managed to remove superuser privileges from his only
superuser.
We thought and though but it seems that there is no way to recover from
this situation except a re-init and reload. And what user is
We have postgres running on a linux machine
and we connect with 15 winnt 4.0 machines running ACCESS2000
When we change from access 97 to access 2000 we get every 15 minutes
following problem
after a process query
-
fatal 1:set user id user admin is not in eg sh
20 matches
Mail list logo