Re: Trying to change the owner of some tables

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: John Scalia <jayknowsunix(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Trying to change the owner of some tables
Date: 2015-06-25 15:10:35
Message-ID: 20150625151035.GJ3289@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

John Scalia wrote:
> 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.

I think the current situation is that the pg_class entries point to one
user, but the pg_shdepend entries point to the original owner. That is
an example case of catalog "corruption" -- or rather inconsistency.

I think what you should do is update pg_class back to the original
state, and then apply REASSIGN OWNED BY. If the new owner had tables
other than those owned by the one you're trying to delete, this would be
pretty complicated, though -- in this case you should probably compare
the pg_shdepend entries to find out which tables were owned by the other
user, so that you know which ones to update. This should doable, if a
bit tricky.

Hopefully this episode demonstrates the folly of updating catalogs "by
hand". I suggest never to do that again, and if somebody else tells you
to, point them here.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message naveen kumar 2015-06-25 15:24:27 Re: dump using copy failed
Previous Message naveen kumar 2015-06-25 14:23:11 Re: PostgreSQL Dump based backup using pipe