Re: Big problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Big problem
Date
Msg-id 11372.1085409248@sss.pgh.pa.us
Whole thread Raw
In response to Re: Big problem  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: Big problem  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: Big problem  (Dennis Bjorklund <db@zigo.dhs.org>)
List pgsql-hackers
Christopher Kings-Lynne <chriskl@familyhealth.com.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


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Big problem
Next
From: Markus Bertheau
Date:
Subject: Re: Big problem