Joseph Kiniry <kiniry@xxxxxxx> writes: > As I said above, I have re-examined, and executed if necessary, by > hand, all sql commands in initdb and postgres.bki, but it seems that > pg_catalog is still screwed up. Attempting to dump, or perform > several other actions results in failures of the form: > ERROR: 42P01: relation "pg_user" does not exist > LOCATION: RangeVarGetRelid, namespace.c:193 > STATEMENT: SELECT (SELECT usename FROM pg_user WHERE usesysid = > datdba) as dba\ > , pg_encoding_to_char(encoding) as encoding, datpath FROM pg_database > WHERE dat\ > name = 'gforge' > So why can I see pg_user and yet pg_dump fails? > gforge=# select * from pg_user; > [ works ] Hmm ... you manually recreated the pg_user view you say? I wonder if you mistakenly put it in the public schema instead of pg_catalog. The quoted command from pg_dump is done after issuing set search_path = pg_catalog; so that nothing user-created will accidentally mess it up. If you can still manually select from pg_user after issuing that same SET command, then something is really seriously strange ... If you find that indeed pg_user is in public, drop it there and re-create it in pg_catalog. You'll need to be superuser to do that but I don't think it'll require any more pushups than that. regards, tom lane
