| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, sergiomb(at)netcabo(dot)pt |
| Subject: | Re: Big problem |
| Date: | 2004-05-24 14:34:08 |
| Message-ID: | 11372.1085409248@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> 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 on pg_shadow grab exclusive lock. For instance, you
couldn't allow two backends to DROP USER in parallel; they might be
dropping the last two superusers, but neither one would think it was
creating a problem. And while we could theoretically make
CREATE/ALTER/DROP USER take such locks, I dunno how you make a straight
"DELETE FROM pg_shadow" do so.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Bertheau | 2004-05-24 14:36:59 | Re: Big problem |
| Previous Message | Christopher Kings-Lynne | 2004-05-24 14:19:20 | Re: Big problem |