Re: How was I able to drop a role even though objects depend on it?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: "Wojciechowski, Robert (GE Transportation)" <wojo(at)ge(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: How was I able to drop a role even though objects depend on it?
Date: 2013-07-01 16:20:21
Message-ID: 20130701162021.GE3757@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Wojciechowski, Robert (GE Transportation) wrote:
> I’ve noticed a weird situation on one of our development servers running PostgreSQL 9.1.3 where roles have been dropped even though objects depend on that user. I didn’t think that was possible due to the dependency checks on DROP USER/ROLE. For example, there is a database that shows this connect grant to a user that was known as foo1_userA (oid 3562339547): 3562339547=c/postgres This happened after a nightly database import script was run that takes in new clone databases from production. After the script imports new databases another script runs that drop all users matching a regex (/^foo1_user/ for example) to clear out stale users. This obviously should succeed dropping a user that does not have dependent objects and should fail on users that do. For some this is not holding true. Is this a bug? Am I relying too much on DROP USER/ROLE? Any alternative approaches to clearing out users that do not have dependent objects or guidance on debugging this situation would be much appreciated! -- Robert

It sounds like a bug to me. Can you provide a self-contained reproducer
of this? It'd be useful to know what kind of objects (should have)
depended on that user, for instance.

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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Marcos Cano 2013-07-01 16:20:45 Re: pg_upgrade / postgis issue
Previous Message Marcos Cano 2013-07-01 16:15:20 Re: pg_upgrade / postgis issue