Re: Backing up and restoring a database with the SELinux pg_user problem.

Hi Tom,

Thank you for the very quick response. I'll let Robin followup on
this for tonight, as I'm heading to bed after a very long day.

On 4 Jul, 2006, at 22:12, Tom Lane wrote:

> Joseph Kiniry <kiniry(at)acm(dot)org> 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 ...

I did notice the above command and executed it by hand. But as to
whether I did it all at the right time, in the right order, to ensure
that everything is in the right schemas... :)

> 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.

We'll double-check this.

> regards, tom lane

Thanks again for the pointer,
Joe
---
Joseph Kiniry
School of Computer Science and Informatics
UCD Dublin
http://secure.ucd.ie/
http://srg.cs.ucd.ie/