Good thought Guillaume, but the only Dbs on this cluster are:
The one I'm working in
postgres
template0
template1
and that's it. Thinking these errant tables might have got created in the postgres db, I did a \c postgres, then did \d in there. It came back with no relations found.
Thanks guys, I was not aware of that command, but it did NOT succeed in changing these strangely missing tables. The tables appear, when I try to drop the old owner as:
second_schema.partition_table_name_one;
then two, three, etc., I've only been successful using
alter table second_schema.partition_table_name_one owner to userB;
But I'd rather not do that for 2000+ entries.
The only reason that would explain why you can't see them with \d and in pg_class is that they are on another database. Same cluster but another database. You should connect to the other databases and use REASSIGN OWNED in each of them.
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.
Now, this is a 9.2 server on CentOS, but I've not seen this behavior anywhere before. Where else should I see these? The only success I've had is \d+ new_schema.* and that doesn't help me change them.
