Tom Lane writes:
> I've been thinking a little bit about how one might recover from Really
> Stupid Mistakes, like deleting one's only superuser pg_shadow entry.
> What I'm thinking is that if we hard-wired usesysid = 1 for the
> superuser, it'd be possible to arrange for standalone backends to
Tom Lane writes:
> What I'm thinking is that if we hard-wired usesysid = 1 for the
> superuser, it'd be possible to arrange for standalone backends to fire
> up with that sysid and superuserness assumed, and not consult pg_shadow
> at all. Then you'd have a platform in which you could do CREATE
Peter Eisentraut wrote:
> We've had some problem reports that the current practice of initdb
> assigning to the postgres user the same usesysid as the user id of the
> Unix user running initdb has caused some clashes.
> ...
> I think the simplest fix would be to assign a fixed usesysid of 1.
I wa
> One idea to resolve this, by getting rid of the usesysid column in favour
> of the oid column has fallen by the wayside (for some valid reasons), so
> the problem remains. I think the simplest fix would be to assign a fixed
> usesysid of 1. There still is the possibility of changing that with
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I think the simplest fix would be to assign a fixed usesysid of 1.
Slightly more flexible: make the ID number an initdb option, with a
default of 1. This would let people do it the old way if they wanted.
Doesn't seem very critical though.
We've had some problem reports that the current practice of initdb
assigning to the postgres user the same usesysid as the user id of the
Unix user running initdb has caused some clashes.
(Imagine this scenario: A few years ago you installed BluePants Linux
5.0, created a user for PostgreSQL, id
