John Scalia <jayknowsunix@xxxxxxxxx> 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 trying to 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 protect the 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 tried to 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 already changed, 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
