Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Uti3P-0001Kg-9j for pgsql-admin@arkaria.postgresql.org; Mon, 01 Jul 2013 17:38:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Uti3O-0003jy-Od for pgsql-admin@arkaria.postgresql.org; Mon, 01 Jul 2013 17:38:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Uti3N-0003js-Vm for pgsql-admin@postgresql.org; Mon, 01 Jul 2013 17:38:18 +0000 Received: from smtprelay0071.b.hostedemail.com ([64.98.42.71] helo=smtprelay.b.hostedemail.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Uti3E-0004qF-JE for pgsql-admin@postgresql.org; Mon, 01 Jul 2013 17:38:17 +0000 Received: from filter.hostedemail.com (b-bigip1 [10.5.19.254]) by smtprelay06.b.hostedemail.com (Postfix) with ESMTP id 3F8E98D237; Mon, 1 Jul 2013 17:38:07 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Panda: scanned! X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, alvherre@alvh.no-ip.org, :::, RULES_HIT:355:379:599:967:973:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1541:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2525:2540:2560:2563:2682:2685:2828:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4416:4605:4659:5007:6261:7904:9025:9121:10004:10400:10848:11232:11256:11257:11658:11914:12517:12519:12555:12679:13069:13161:13229:13311:13357:13870:13894:13895, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none, Custom_rules:0:0:0 X-HE-Tag: bells70_298b69fa0d159 X-Filterd-Recvd-Size: 2346 Received: from eldon.alvh.no-ip.org (unknown [200.126.64.69]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf10.b.hostedemail.com (Postfix) with ESMTPA; Mon, 1 Jul 2013 17:38:05 +0000 (UTC) Received: by eldon.alvh.no-ip.org (Postfix, from userid 1000) id 1F0D11FC5; Mon, 1 Jul 2013 13:38:04 -0400 (CLT) Date: Mon, 1 Jul 2013 13:38:04 -0400 From: Alvaro Herrera To: David Johnston Cc: pgsql-admin@postgresql.org Subject: Re: How was I able to drop a role even though objects depend on it? Message-ID: <20130701173803.GI3757@eldon.alvh.no-ip.org> References: <59BF48FAC524384DA413D8F4F2E4BA6907D9A9DA@CINURCNA06.e2k.ad.ge.com> <1372697164049-5762060.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1372697164049-5762060.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org David Johnston wrote: > Wojciechowski, Robert (GE Transportation) wrote > > [...] there is a database that shows this connect grant to a user that was > > known as foo1_userA (oid 3562339547): 3562339547=c/postgres > > The main user dependent situation is having said user OWNER on a database > object. Simply giving a user connect privileges on a database does not make > the database dependent upon said user and so removing said user remains > possible. Dropping a user which is either a database owner or has been granted CONNECT privileges is supposed to be disallowed: alvherre=# create user f; CREATE ROLE alvherre=# create database f owner f; CREATE DATABASE alvherre=# drop role f; ERROR: role "f" cannot be dropped because some objects depend on it DETALLE: owner of database f alvherre=# create role g; CREATE ROLE alvherre=# grant connect on database f to g; GRANT alvherre=# drop role g; ERROR: role "g" cannot be dropped because some objects depend on it DETALLE: privileges for database f We're supposed to have sufficient locking so that concurrent transactions don't see problems either (one xact drops the user while the other creates the database), but maybe there are bugs somewhere. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin