"Marc Sherman" <[EMAIL PROTECTED]> writes:
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>> Sounds like you have no pg_shadow entry for the postgres user.
> No, that's not it:
> template1=# select * from pg_shadow;
> usename | usesysid | usecreatedb | usetrace | usesuper | usecatupd |
> passwd | valuntil
> ----------+----------+-------------+----------+----------+-----------+------
> --+----------
> postgres | 31 | t | t | t | t |
> |
> msherman | 1000 | t | f | f | f |
> |
> www-data | 33 | f | f | f | f |
> |
> (3 rows)
> This is strange, though -- the problem types have typowner set
> to 103 in pg_type, which is clearly invalid. 103 happens to be
> the Linux user ID (in passwd) for the postgres user. Strange.
> I suspect this may be a problem with the Debian install scripts;
> Debian is forcing postgres' user id to be 31 in the db, since it
> used to use a reserved user id for postgres in the os.
Either that or a bug in initdb: it *should* substitute the same ID into
postgres' pg_shadow entry as it does into the owner columns of the
template1 system catalogs. Maybe it's getting confused. Oliver,
any thoughts?
> Is it enough for me to log on to each of my databases as user
> postgres, and execute the query "update pg_type set typowner=31
> where typowner=103;" to fix this problem? Are there any other
> hidden databases I should fix besides template1?
Aside from pg_type, you probably have bogus values in the owner columns
for pg_class, pg_function, pg_operator, etc etc. It'd be a lot easier
to create another user with sysid = 103 ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
