John Scalia <jayknowsunix@gmail.com> writes:
> I'm trying to build a new server from a copy of one of our live Dbs, and I imported the schema from there and am now
tryingto get this new server setup with the right ownership
> and permissions. All the tables are/were owned by user A, and I've changed most of them to user B (names changed to
protectthe innocent, etc.,) However, some tables from the
> pg_dump I used to grab the schema, do not show up using \d nor can I see them in pg_class. I only found them when I
triedto drop user A and psql complained. They appear to be in a
> different schema and I could change them one at a time, but there are more than 2200 of these. For the tables I've
alreadychanged, I just performed an update on pg_class where
> relowner = numeric ID of user A to set that to the numeric ID of user B.
That was a seriously bad idea.
The problem that you now have is that pg_class.relowner is out of sync
with the ownership data in pg_shdepend. As Alvaro said, it's also going
to be out of sync with pg_class.relacl, if any of those tables had
explicit GRANTs.
REASSIGN OWNED, by itself, will not fix this situation since it relies on
pg_class.relowner to decide which objects need to be reassigned. What you
need to do is undo that manual catalog hacking and then use REASSIGN OWNED
to get to where you wanted to be.
If you don't remember exactly which tables you changed manually, you could
probably do a join against pg_shdepend to find them: look for tables that
have a matching pg_shdepend row but the relowner doesn't match the
refobjid.
regards, tom lane